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
| ||
|
Message-ID: <20230411182243.120bf51e@hermes.local> 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.
Powered by blists - more mailing lists