Re: neighbour netlink notifications delivered in wrong order

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 7 Jun 2022 09:29:45 -0700
Francesco Ruggeri <fruggeri@arista.com> wrote:

> On Mon, Jun 6, 2022 at 8:19 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Mon, 6 Jun 2022 19:07:04 -0700
> > Andy Roulin <aroulin@nvidia.com> wrote:
> >  
> > > diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> > > index 54625287ee5b..a91dfcbfc01c 100644
> > > --- a/net/core/neighbour.c
> > > +++ b/net/core/neighbour.c
> > > @@ -2531,23 +2531,19 @@ static int neigh_fill_info(struct sk_buff *skb,
> > > struct neighbour *neigh,
> > >       if (nla_put(skb, NDA_DST, neigh->tbl->key_len, neigh->primary_key))
> > >               goto nla_put_failure;
> > >
> > > -     read_lock_bh(&neigh->lock);
> > >       ndm->ndm_state   = neigh->nud_state;  
> >
> > Accessing neighbor state outside of lock is not safe.
> >
> > But you should be able to use RCU here??  
> 
> I think the patch removes the lock from neigh_fill_info but it then uses it
> to protect all calls to neigh_fill_info, so the access should still be safe.
> In case of __neigh_notify the lock also extends to protect rtnl_notify,
> guaranteeing that the state cannot be changed while the notification
> is in progress (I assume all state changes are protected by the same lock).
> Andy, is that the idea?

Neigh info is already protected by RCU, is per neighbour reader/writer lock
still needed at all?