On Tue, Apr 23, 2019 at 03:16:19PM +0200, Florian Westphal wrote: > 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. Acked-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
