diff options
author | Florian Westphal <fw@strlen.de> | 2019-04-23 15:16:24 +0200 |
---|---|---|
committer | Florian Westphal <fw@strlen.de> | 2019-04-27 01:08:51 +0200 |
commit | 58d7de0181f61570bdf9ba2b88964d5009860c39 (patch) | |
tree | 0967d1635fe08a85448248c62688ad0bd52d9e40 /extensions/libxt_connlabel.t | |
parent | 77e6a93d5c9dcb58c3e573c9a14710fadbbc001a (diff) |
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>
Diffstat (limited to 'extensions/libxt_connlabel.t')
0 files changed, 0 insertions, 0 deletions