Messages in this thread | | | Date | Thu, 10 Jan 2019 21:25:33 +0100 | From | Peter Zijlstra <> | Subject | Re: seqcount usage in xt_replace_table() |
| |
On Thu, Jan 10, 2019 at 03:48:12PM +0100, Florian Westphal wrote: > Peter Zijlstra <peterz@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?
| |