aboutsummaryrefslogtreecommitdiffstats
path: root/net/bridge/br_netfilter.c
diff options
context:
space:
mode:
authorPablo Neira Ayuso <pablo@netfilter.org>2014-09-04 14:30:22 +0200
committerPablo Neira Ayuso <pablo@netfilter.org>2014-09-19 11:14:43 +0200
commit84d7fce693884897c6196cc98228a2ad56ae2a9a (patch)
treed29751d76c35bc6efb5042ba24486be823173dcb /net/bridge/br_netfilter.c
parentnetfilter: nfnetlink: use original skbuff when committing/aborting (diff)
downloadlinux-dev-84d7fce693884897c6196cc98228a2ad56ae2a9a.tar.xz
linux-dev-84d7fce693884897c6196cc98228a2ad56ae2a9a.zip
netfilter: nf_tables: export rule-set generation ID
This patch exposes the ruleset generation ID in three ways: 1) The new command NFT_MSG_GETGEN that exposes the 32-bits ruleset generation ID. This ID is incremented in every commit and it should be large enough to avoid wraparound problems. 2) The less significant 16-bits of the generation ID are exposed through the nfgenmsg->res_id header field. This allows us to quickly catch if the ruleset has change between two consecutive list dumps from different object lists (in this specific case I think the risk of wraparound is unlikely). 3) Userspace subscribers may receive notifications of new rule-set generation after every commit. This also provides an alternative way to monitor the generation ID. If the events are lost, the userspace process hits a overrun error, so it knows that it is working with a stale ruleset anyway. Patrick spotted that rule-set transformations in userspace may take quite some time. In that case, it annotates the 32-bits generation ID before fetching the rule-set, then: 1) it compares it to what we obtain after the transformation to make sure it is not working with a stale rule-set and no wraparound has ocurred. 2) it subscribes to ruleset notifications, so it can watch for new generation ID. This is complementary to the NLM_F_DUMP_INTR approach, which allows us to detect an interference in the middle one single list dumping. There is no way to explicitly check that an interference has occurred between two list dumps from the kernel, since it doesn't know how many lists the userspace client is actually going to dump. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Diffstat (limited to 'net/bridge/br_netfilter.c')
0 files changed, 0 insertions, 0 deletions