[PATCH xtables-nft 0/6] handle parallel restore case

[Florian Westphal <fw@strlen.de>]

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(-)