path: root/tests/shell
diff options
authorPhil Sutter <>2018-10-26 11:42:05 +0200
committerPablo Neira Ayuso <>2018-10-29 11:15:08 +0100
commit21d678639b28b99c301262c163128fdf67397ca6 (patch)
tree61c0724827e2327f2a7e37b58878a5ae339d080c /tests/shell
parent7b6f95df9eb6d9f51b2e99ba335e7b57e9a451df (diff)
tests/shell: Add testcase for cache update problems
The first test in there shows how the current cache update strategy causes trouble. The second test shows that proposed "locking" of cache when local entries are added is flawed, too. Signed-off-by: Phil Sutter <> Signed-off-by: Pablo Neira Ayuso <>
Diffstat (limited to 'tests/shell')
1 files changed, 29 insertions, 0 deletions
diff --git a/tests/shell/testcases/cache/0003_cache_update_0 b/tests/shell/testcases/cache/0003_cache_update_0
new file mode 100755
index 00000000..deb45db2
--- /dev/null
+++ b/tests/shell/testcases/cache/0003_cache_update_0
@@ -0,0 +1,29 @@
+set -e
+# Expose how naive cache update logic (i.e., drop cache and repopulate from
+# kernel ruleset) may mess things up. The following input does:
+# list ruleset -> populate the cache, cache->genid is non-zero
+# add table ip t -> make kernel's genid increment (cache->genid remains
+# unchanged)
+# add table ip t2; -> first command of batch, new table t2 is added to the cache
+# add chain ip t2 c -> second command of batch, triggers cache_update() which
+# removes table t2 from it
+$NFT -i >/dev/null <<EOF
+list ruleset
+add table ip t
+add table ip t2; add chain ip t2 c
+# The following test exposes a problem with simple locking of cache when local
+# entries are added:
+# add table ip t3 -> cache would be locked without previous update
+# add chain ip t c -> table t is not found due to no cache update happening
+$NFT -i >/dev/null <<EOF
+add table ip t3; add chain ip t c