From: Phil Sutter <phil@nwl.cc>
Date: Fri, 26 Oct 2018 09:42:05 +0000 (+0200)
Subject: tests/shell: Add testcase for cache update problems
X-Git-Tag: v0.9.1~202
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=21d678639b28b99c301262c163128fdf67397ca6;p=thirdparty%2Fnftables.git

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 <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---

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