This series handles the case of parallel iptables-nft-restore
invocations.
As xtables-nft ignores -w option (userspace-based serialization
lock), several nft instances can race.
In worse case, we can restore a ruleset twice, i.e. we get
duplicated rules:
1. "iptables-nft-restore < foo" is called for first time.
No tables exist, so we create a transaction that creates
the table/chains/rules.
2. "iptables-nft-restore < foo" is called in parallel.
If the timing is right, it will also find no existing table,
and will create a 2nd batch that adds rules.
If the 2nd version doesn't run in parallel, it will detect
that the table exists and will add a flush operation to the
batch.
The first patches are preparation work, the fix is coming in patch 5,
it uses the generation counter to detect when the transaction batch
was based off an old state.
In case kernel indicates the generation id doesn't match anymore,
we fetch the current state and will refresh the pending transaction
before re-try.
The refresh currently includes adding/removing flush and chain add
operations.
Last patch adds a test script for this.
Florian Westphal (6):
xtables: unify user chain add/flush for restore case
xtables: add skip flag to objects
xtables: add and use nft_build_cache
xtables: add and set "implict" flag on transaction objects
xtables: handle concurrent ruleset modifications
tests: add test script for race-free restore
nft-shared.h | 7
nft.c | 325 +++++++++++++-----
nft.h | 7
tests/shell/testcases/ipt-restore/0004-restore-race_0 | 119 ++++++
xtables-restore.c | 35 -
xtables-translate.c | 6
6 files changed, 379 insertions(+), 120 deletions(-)
