From 802c96c0b2061dbab20694184bebbeba5eda4a03 Mon Sep 17 00:00:00 2001
From: Phil Sutter <phil@nwl.cc>
Date: Fri, 26 Oct 2018 11:42:05 +0200
Subject: [PATCH] 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>
(cherry picked from commit 21d678639b28b99c301262c163128fdf67397ca6)
Signed-off-by: Phil Sutter <psutter@redhat.com>
---
 .../shell/testcases/cache/0003_cache_update_0 | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100755 tests/shell/testcases/cache/0003_cache_update_0

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 0000000000000..deb45db2c43be
--- /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
-- 
2.22.0