[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260125145922.36ba88ad@kernel.org>
Date: Sun, 25 Jan 2026 14:59:22 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Petr Machata <petrm@...dia.com>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon Horman
<horms@...nel.org>, <netdev@...r.kernel.org>, 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>,
<mlxsw@...dia.com>
Subject: Re: [PATCH net-next v2 6/8] net: core: neighbour: Reorder netlink &
internal notification
On Wed, 21 Jan 2026 17:43:40 +0100 Petr Machata wrote:
> 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.)
Hopefully we're not setting a trap here that some driver will later
fall into.
Powered by blists - more mailing lists