On Wed, 2024-01-17 at 17:28 +0100, Eric Dumazet wrote: > On Wed, Jan 17, 2024 at 5:23 PM Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxx> wrote: > > > > Hi, > > > > On Wed, 17 Jan 2024, Eric Dumazet wrote: > > > > > On Wed, Jan 17, 2024 at 5:00 PM Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > > > > > > From: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxx> > > > > > > > > The patch "netfilter: ipset: fix race condition between swap/destroy > > > > and kernel side add/del/test", commit 28628fa9 fixes a race condition. > > > > But the synchronize_rcu() added to the swap function unnecessarily slows > > > > it down: it can safely be moved to destroy and use call_rcu() instead. > > > > Thus we can get back the same performance and preventing the race condition > > > > at the same time. > > > > > > ... > > > > > > > > > > > @@ -2357,6 +2369,9 @@ ip_set_net_exit(struct net *net) > > > > > > > > inst->is_deleted = true; /* flag for ip_set_nfnl_put */ > > > > > > > > + /* Wait for call_rcu() in destroy */ > > > > + rcu_barrier(); > > > > + > > > > nfnl_lock(NFNL_SUBSYS_IPSET); > > > > for (i = 0; i < inst->ip_set_max; i++) { > > > > set = ip_set(inst, i); > > > > -- > > > > 2.30.2 > > > > > > > > > > If I am reading this right, time for netns dismantles will increase, > > > even for netns not using ipset > > > > > > If there is no other option, please convert "struct pernet_operations > > > ip_set_net_ops".exit to an exit_batch() handler, > > > to at least have a factorized rcu_barrier(); > > > > You are right, the call to rcu_barrier() can safely be moved to > > ip_set_fini(). I'm going to prepare a new version of the patch. > > > > Thanks for catching it. > > I do not want to hold the series, your fix can be built as another > patch on top of this one. Given the timing, if we merge this series as is, it could go very soon into Linus' tree. I think it would be better to avoid introducing known regressions there. Any strong opinions vs holding this series until the problems are fixed? Likely a new PR will be required. Thanks, Paolo