On 16.01, Thomas Graf wrote: > On 01/16/15 at 10:07pm, Patrick McHardy wrote: > > I'm afraid that's not good enough. The resize operation is deferred, > > so even if userspace does not perform an operation after starting > > the dump, the hash might change. > > > > We can obviously work around that by incrementing a generation > > counter in rhashtable. The main problem I see is that with something > > very actively changing the ruleset, we might never complete a dump. > > Right, I suggest adding a function pointer to rhashtable_params, > which when set, is called on resize so users can bump their own > sequence counter on resize. > > > Dumps are usually rare, I think its preferrable to defer rehashing. > > Resize operations should be *really* rare as well unless you start > with really small hash table sizes and constantly add/remove at the > watermark. Which are far enough from each other that this should only happen in really unlucky cases. > Re-dumping on insert/remove is a different story of course. Do you > care about missed insert/removals for dumps? If not we can do the > sequence number consistency checking for resizing only. No, that has always been undeterministic with netlink. We want to dump everything that was present when the dump was started and is still present when it finishes. Anything else can be handled using notifications. -- 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
