On 2025-02-17 15:05:38 [+0100], Florian Westphal wrote:
> 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).
Urgh. Is this fast & frequent update a real-world thing or a benchmark
of some sort? I mean adding rule after rule is possible but…
I used here synchronize_rcu() and there is also
synchronize_rcu_expedited() but I do hate it. With everything.
What are the counters used in userland for? I've seen that they are
copied but did not understood why.
iptables-legacy -A INPUT -j ACCEPT
ends up in xt_replace_table() but iptables-nft doesn't. Different
interface, better design? Or I just used legacy and now it is considered
as the only?
I see two invocations on iptables-legacy-restore.
But the question remains: Why copy counters after replacing the rule
set?
Sebastian
