On Thu, Sep 11, 2014 at 06:10:40PM +0200, Pablo Neira Ayuso wrote: > 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. I don't think that's a really good idea since the ordering between the rule notifications and the commit notification wouldn't be reliable. Same thing is probably true for state notifications, not entirely sure yet if they could reasonably be sent to a different group. -- 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
