On Thu, Sep 11, 2014 at 04:32:44PM +0100, Patrick McHardy wrote: > On Thu, Sep 11, 2014 at 05:20:19PM +0200, Pablo Neira Ayuso wrote: > > 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 is 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. > > Correct, there's just one thing to consider here, which is what happens > once we add active ruleset state notifications, like counters, limit > etc. At that point its not clear anymore whether changes have happened. > OTOH it would be just a false positive, so at least things would keep > working. Right, I can put the genid notification in a different nfnetlink multicast group (NFNLGRP_NFTABLES_GENID) to avoid false positives if you like the idea, we have plenty of spare groups. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
