summaryrefslogtreecommitdiffstats
path: root/iptables/tests/shell/testcases/ipt-restore/0016-concurrent-restores_0
Commit message (Collapse)AuthorAgeFilesLines
* tests: shell: Improve concurrent noflush restore test a bitPhil Sutter2020-10-271-0/+14
| | | | | | | | | | | | The described issue happens only if chain FOO does not exist at program start so flush the ruleset after each iteration to make sure this is the case. Sadly the bug is still not 100% reproducible on my testing VM. While being at it, add a paragraph describing what exact situation the test is trying to provoke. Fixes: dac904bdcd9a1 ("nft: Fix for concurrent noflush restore calls") Signed-off-by: Phil Sutter <phil@nwl.cc>
* nft: Fix for concurrent noflush restore callsPhil Sutter2020-10-131-0/+53
Transaction refresh was broken with regards to nft_chain_restore(): It created a rule flush batch object only if the chain was found in cache and a chain add object only if the chain was not found. Yet with concurrent ruleset updates, one has to expect both situations: * If a chain vanishes, the rule flush job must be skipped and instead the chain add job become active. * If a chain appears, the chain add job must be skipped and instead rules flushed. Change the code accordingly: Create both batch objects and set their 'skip' field depending on the situation in cache and adjust both in nft_refresh_transaction(). As a side-effect, the implicit rule flush becomes explicit and all handling of implicit batch jobs is dropped along with the related field indicating such. Reuse the 'implicit' parameter of __nft_rule_flush() to control the initial 'skip' field value instead. A subtle caveat is vanishing of existing chains: Creating the chain add job based on the chain in cache causes a netlink message containing that chain's handle which the kernel dislikes. Therefore unset the chain's handle in that case. Fixes: 58d7de0181f61 ("xtables: handle concurrent ruleset modifications") Signed-off-by: Phil Sutter <phil@nwl.cc>