On Thu, Jan 10, 2019 at 03:48:12PM +0100, Florian Westphal wrote: > Peter Zijlstra <pet...@infradead.org> wrote: > > Is performance a concern in this path? There is no comment justifying > > this 'creative' stuff. > > We have to wait until all cpus are done with current iptables ruleset. > > Before this 'creative' change, this relied on get_counters > synchronization. And that caused wait times of 30 seconds or more on > busy systems. > > I have no objections swapping this with a synchronize_rcu() if that > makes it easier.
Would using synchronize_rcu() not also mean you can get rid of that xt_write_recseq*() stuff entirely? Anyway, synchronize_rcu() can also take a little while, but I don't think anywere near 30 seconds. > (synchronize_rcu might be confusing though, as we don't use rcu > for table->private), and one 'has to know' that all the netfilter > hooks, including the iptables eval loop, run with rcu_read_lock > held). A comment can help there, right?
