Re: neighbour netlink notifications delivered in wrong order

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 7 Jun 2022 20:49:40 -0700
Andy Roulin <aroulin@nvidia.com> wrote:

> On 6/7/22 1:03 PM, Francesco Ruggeri wrote:
> > On Tue, Jun 7, 2022 at 10:32 AM Stephen Hemminger
> > <stephen@networkplumber.org> wrote:  
> >>
> >> 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?  
> 
> Yes correct.
> 
> >>
> >> Neigh info is already protected by RCU, is per neighbour reader/writer lock
> >> still needed at all?  
> > 
> > The goal of the patch seems to be to make changing a neighbour's state and
> > delivering the corresponding notification atomic, in order to prevent
> > reordering of notifications. It uses the existing lock to do so.
> > Can reordering be prevented if the lock is replaced with rcu?  
> 
> Yes that's the goal of the patch. I'd have to look in more details if 
> there's a better solution with RCU.

But the patch would update ndm->ndm_state based on neigh, but there
is nothing ensuring that neigh is not going to be deleted or modified.