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

On Tue, Sep 01, 2026 at 06:32:49PM +0000, Kuniyuki Iwashima wrote:

quoted

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.