Messages in this thread | | | Date | Thu, 10 Jan 2019 13:41:23 +0100 | From | Peter Zijlstra <> | Subject | Re: seqcount usage in xt_replace_table() |
| |
On Tue, Jan 08, 2019 at 11:37:46PM +0100, Florian Westphal wrote: > Anatol Pomozov <anatol.pomozov@gmail.com> wrote: > > Or maybe xt_replace_table() can be enhanced? When I hear that > > something waits until an event happens on all CPUs I think about > > wait_event() function. Would it be better for xt_replace_table() to > > introduce an atomic counter that is decremented by CPUs, and the main > > CPU waits until the counter gets zero? > > That would mean placing an additional atomic op into the > iptables evaluation path (ipt_do_table and friends). >
For:
/* * Ensure contents of newinfo are visible before assigning to * private. */ smp_wmb(); table->private = newinfo;
we have:
smp_store_release(&table->private, newinfo);
But what store does that second smp_wmb() order against? The comment:
/* make sure all cpus see new ->private value */ smp_wmb();
makes no sense what so ever, no smp_*() barrier can provide such guarantees.
> Only alternative I see that might work is synchronize_rcu (the > _do_table functions are called with rcu read lock held). > > I guess current scheme is cheaper though.
Is performance a concern in this path? There is no comment justifying this 'creative' stuff.
| |