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. 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. -- 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
