From 21d678639b28b99c301262c163128fdf67397ca6 Mon Sep 17 00:00:00 2001 From: Phil Sutter Date: Fri, 26 Oct 2018 11:42:05 +0200 Subject: 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 --- tests/shell/testcases/cache/0003_cache_update_0 | 29 +++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100755 tests/shell/testcases/cache/0003_cache_update_0 (limited to 'tests/shell/testcases/cache') 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 < 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 <