On Thu, Sep 11, 2014 at 06:57:31PM +0200, Pablo Neira Ayuso wrote: > On Thu, Sep 11, 2014 at 05:45:58PM +0100, Patrick McHardy wrote: > > 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. > > Indeed, we have to stick to one single group. Oh, you can subscribe to several groups from one single socket. So you get them notifications in order. IIRC, the grouping just provides a way to filter out what you don't want to listen. -- 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
