The netlink message needs to be send inside the critical section where the neighbor is changed, so that it reflects the notified-upon neighbor state. On the other hand, there is no such need in case of notifier chain: 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. This requires that the netlink notification be done before the internal notifier chain message is sent. That is safe to do, because the current listeners, as well as __neigh_notify(), only read the updated neighbor fields, and never modify them. (Apart from locking.) Signed-off-by: Petr Machata Reviewed-by: Ido Schimmel --- net/core/neighbour.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 0fbdaae7df99..187615bcc1c3 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -1187,8 +1187,8 @@ static void neigh_timer_handler(struct timer_list *t) } if (notify) { - call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh); neigh_notify(neigh, RTM_NEWNEIGH, 0, 0); + call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh); } trace_neigh_timer_handler(neigh, 0); @@ -1523,8 +1523,8 @@ static int __neigh_update(struct neighbour *neigh, const u8 *lladdr, neigh_update_managed_list(neigh); if (notify) { - call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh); neigh_notify(neigh, RTM_NEWNEIGH, 0, nlmsg_pid); + call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh); } trace_neigh_update_done(neigh, err); -- 2.51.1