Re: [PATCH v5 net-next 00/15] neighbour: Namespacify arp_tbl and nd_tbl.

[Ido Schimmel <idosch@nvidia.com>]

On Tue, Sep 01, 2026 at 06:32:49PM +0000, Kuniyuki Iwashima wrote:
> The neighbour subsystem is almost ready to drop RTNL.
> 
> However, the control paths are serialised by the global
> per-table lock.
> 
> This series converts arp_tbl and nd_tbl to per-netns table.
> 
> With the series, /proc/sys/net/ipv{4,6}/neigh/default/ can
> be configured per netns, which was only configurable in
> init_net.

LGTM overall. Two notes:

1. The two periodic works (GC and the one for "managed" entries) are now
per-netns, including their intervals. An unpriv user can set an interval
of 0 and hog the CPU. Previously you needed CAP_NET_ADMIN in the init
netns.

neigh_managed_work() already has a floor for the re-queue delay since
commit ed6cd6a17896 ("net, neigh: Set lower cap for neigh_managed_work
rearming"). We need something similar for neigh_periodic_work().
Something like:

diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 27602bcbeb69..17817e30944b 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1038,7 +1038,8 @@ static void neigh_periodic_work(struct work_struct *work)
 	 * BASE_REACHABLE_TIME.
 	 */
 	queue_delayed_work(system_power_efficient_wq, &tbl->gc_work,
-			      NEIGH_VAR(&tbl->parms, BASE_REACHABLE_TIME) >> 1);
+			   max(NEIGH_VAR(&tbl->parms, BASE_REACHABLE_TIME) >> 1,
+			       HZ));
 	spin_unlock_bh(&tbl->lock);
 }

2. Related to the first point, we are now going to schedule periodic
work per-netns for "managed" entries which are quite exotic. Better to
schedule it only when we have such entries instead of unconditionally
from neigh_table_init().

I think both can be done in a follow-up given you are already at 15
patches. The first is more critical, obviously.

Thanks!