Re: neighbour netlink notifications delivered in wrong order

From: Stephen Hemminger <stephen@networkplumber.org>
To: Andy Roulin <aroulin@nvidia.com>
Cc: Francesco Ruggeri <fruggeri@arista.com>, netdev@vger.kernel.org
Subject: Re: neighbour netlink notifications delivered in wrong order
Date: Tue, 11 Apr 2023 18:22:43 -0700	[thread overview]
Message-ID: <20230411182243.120bf51e@hermes.local> (raw)
In-Reply-To: <20230411174131.634e35d3@hermes.local>

On Tue, 11 Apr 2023 17:41:31 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:

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

Yes there is nothing that prevents an incoming packet changing the contents
of a neighbour entry

> > > 
> > > 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.

Making the update atomic would require a redesign of the locking here.
The update would have to acquire the write lock, modify, then call
the code that generates the message; drop the write lock and then
queue the message to the netlink socket.