On Wed, Oct 11, 2017 at 7:26 AM, Florian Westphal <f...@strlen.de> wrote:
> xt_replace_table relies on table replacement counter retrieval (which
> uses xt_recseq to synchronize pcpu counters).
>
> This is fine, however with large rule set get_counters() can take
> a very long time -- it needs to synchronize all counters because
> it has to assume concurrent modifications can occur.
>
> Make xt_replace_table synchronize by itself by waiting until all cpus
> had an even seqcount.
>
> This allows a followup patch to copy the counters of the old ruleset
> without any synchonization after xt_replace_table has completed.
>
> Cc: Dan Williams <d...@redhat.com>
> Cc: Eric Dumazet <eduma...@google.com>
> Signed-off-by: Florian Westphal <f...@strlen.de>
> ---
> v3: check for 'seq is uneven' OR 'has changed' since
> last check. Its fine if seq is uneven iff its a different
> sequence number than the initial one.
>
> v2: fix Erics email address
> net/netfilter/x_tables.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
>
Reviewed-by: Eric Dumazet <eduma...@google.com>
But it seems we need an extra smp_wmb() after
smp_wmb();
table->private = newinfo;
+ smp_wmb();
Otherwise we have no guarantee other cpus actually see the new ->private value.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
