Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote:
> The seqcount xt_recseq is used to synchronize the replacement of
> xt_table::private in xt_replace_table() against all readers such as
> ipt_do_table(). After the pointer is replaced, xt_register_target()
> iterates over all per-CPU xt_recseq to ensure that none of CPUs is
> within the critical section.
> Once this is done, the old pointer can be examined and deallocated
> safely.
>
> This can also be achieved with RCU: Each reader of the private pointer
> will be with in an RCU read section. The new pointer will be published
> with rcu_assign_pointer() and synchronize_rcu() is used to wait until
> each reader left its critical section.
Note we had this before and it was reverted in
d3d40f237480 ("Revert "netfilter: x_tables: Switch synchronization to RCU"")
I'm not saying its wrong, but I think you need a plan b when the same
complaints wrt table replace slowdown come in.
And unfortunately I can't find a solution for this, unless we keep
either the existing wait-scheme for counters sake or we accept
that some counter update might be lost between copy to userland and
destruction (it would need to use rcu_work or similar, the xt
target/module destroy callbacks can sleep).
