]> git.ipfire.org Git - thirdparty/iptables.git/commit
xtables: handle concurrent ruleset modifications
authorFlorian Westphal <fw@strlen.de>
Tue, 23 Apr 2019 13:16:24 +0000 (15:16 +0200)
committerFlorian Westphal <fw@strlen.de>
Fri, 26 Apr 2019 23:08:51 +0000 (01:08 +0200)
commit58d7de0181f61570bdf9ba2b88964d5009860c39
tree0967d1635fe08a85448248c62688ad0bd52d9e40
parent77e6a93d5c9dcb58c3e573c9a14710fadbbc001a
xtables: handle concurrent ruleset modifications

We currently race when several xtables-nft-restore processes attempt to
handle rules in parallel.  For instance, when no rules are present at
all, then

iptables-nft-restore < X & iptables-nft-restore < X

... can cause rules to be restored twice.

Reason is that both processes might detect 'no rules exist', so
neither issues a flush operation.

We can't unconditionally issue the flush, because it would
cause kernel to fail with -ENOENT unless the to-be-flushed table
exists.

This change passes the generation id that was used to build
the transaction to the kernel.

In case another process changed *any* rule somewhere, the transaction
will now fail with -ERESTART.

We then flush the cache, re-fetch the ruleset and refresh
our transaction.

For example, in the above 'parallel restore' case, the iptables-restore
instance that lost the race would detect that the table has been created
already, and would add the needed flush.

In a similar vein, in case --noflush is used, we will add the flush
op for user-defined chains that were created in the mean-time.

Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
iptables/nft.c
iptables/nft.h