blob: deb45db2c43be7e88bfa20a1fda73141fbcf4b93 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
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
|
