netdev - Re: neighbour netlink notifications delivered in wrong order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 11 Apr 2023 18:22:43 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Andy Roulin <aroulin@...dia.com>
Cc:     Francesco Ruggeri <fruggeri@...sta.com>, netdev@...r.kernel.org
Subject: Re: neighbour netlink notifications delivered in wrong order

On Tue, 11 Apr 2023 17:41:31 -0700
Stephen Hemminger <stephen@...workplumber.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.