summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rwxr-xr-xtests/shell/testcases/cache/0003_cache_update_029
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 @@
+#!/bin/bash
+
+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
+EOF
+
+# 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
+EOF