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@xxxxxx> --- .../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.19.0
