[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1528224375ebd8789994668a286fb3105dbb2c4.1768225160.git.petrm@nvidia.com>
Date: Wed, 14 Jan 2026 10:54:48 +0100
From: Petr Machata <petrm@...dia.com>
To: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
<netdev@...r.kernel.org>
CC: Ido Schimmel <idosch@...dia.com>, Kuniyuki Iwashima <kuniyu@...gle.com>,
Breno Leitao <leitao@...ian.org>, Andy Roulin <aroulin@...dia.com>,
"Francesco Ruggeri" <fruggeri@...sta.com>, Stephen Hemminger
<stephen@...workplumber.org>, Petr Machata <petrm@...dia.com>,
<mlxsw@...dia.com>
Subject: [PATCH net-next 5/8] net: core: neighbour: Inline neigh_update_notify() calls
The obvious idea behind the helper is to keep together the two bits that
should be done either both or neither: the internal notifier chain message,
and the netlink notification.
To make sure that the notification sent reflects the change being made, the
netlink message needs to be send inside the critical section where the
neighbor is changed. But for the notifier chain, there is no such need: the
listeners do not assume lock, and often in fact just schedule a delayed
work to act on the neighbor later. At least one in fact also takes the
neighbor lock. Therefore these two items have each different locking needs.
Now we could unlock inside the helper, but I find that error prone, and the
fact that the notification is conditional in the first place does not help
to make the call site obvious.
So in this patch, the helper is instead removed and the body, which is just
these two calls, inlined. That way we can use each notifier independently.
Signed-off-by: Petr Machata <petrm@...dia.com>
Reviewed-by: Ido Schimmel <idosch@...dia.com>
---
net/core/neighbour.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index f3290385db68..e37db91c5339 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -52,7 +52,6 @@ do { \
static void neigh_timer_handler(struct timer_list *t);
static void neigh_notify(struct neighbour *n, int type, int flags, u32 pid);
-static void neigh_update_notify(struct neighbour *neigh, u32 nlmsg_pid);
static void pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev,
bool skip_perm);
@@ -1187,8 +1186,10 @@ static void neigh_timer_handler(struct timer_list *t)
write_unlock(&neigh->lock);
}
- if (notify)
- neigh_update_notify(neigh, 0);
+ if (notify) {
+ call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh);
+ neigh_notify(neigh, RTM_NEWNEIGH, 0, 0);
+ }
trace_neigh_timer_handler(neigh, 0);
@@ -1520,8 +1521,12 @@ static int __neigh_update(struct neighbour *neigh, const u8 *lladdr,
neigh_update_gc_list(neigh);
if (managed_update)
neigh_update_managed_list(neigh);
- if (notify)
- neigh_update_notify(neigh, nlmsg_pid);
+
+ if (notify) {
+ call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh);
+ neigh_notify(neigh, RTM_NEWNEIGH, 0, nlmsg_pid);
+ }
+
trace_neigh_update_done(neigh, err);
return err;
}
@@ -2750,12 +2755,6 @@ static int pneigh_fill_info(struct sk_buff *skb, struct pneigh_entry *pn,
return -EMSGSIZE;
}
-static void neigh_update_notify(struct neighbour *neigh, u32 nlmsg_pid)
-{
- call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh);
- neigh_notify(neigh, RTM_NEWNEIGH, 0, nlmsg_pid);
-}
-
static bool neigh_master_filtered(struct net_device *dev, int master_idx)
{
struct net_device *master;
--
2.51.1
Powered by blists - more mailing lists