Subject: Re: [PATCH net 1/1] ovpn: fix race between deleting interface and adding new peer

From: Jakub Kicinski <[email-masked]>
Date: Mon, 27 Apr 2026 13:22:31 -0700

On Fri, 24 Apr 2026 00:27:10 +0200 Sabrina Dubroca wrote:
> 2026-04-23, 10:36:28 -0700, Jakub Kicinski wrote:
> > On Thu, 23 Apr 2026 18:37:49 +0200 Sabrina Dubroca wrote:  
> > > We could also wrap all of ovpn_peer_add (including the new reg_state
> > > check) in netdev_lock, since we can't move to NETREG_UNREGISTERING
> > > until netdev_lock is released (then I think we wouldn't need the
> > > READ_ONCE(reg_state)). But I don't know if that's an acceptable use of
> > > netdev_lock.  
> > 
> > Yup, fwiw it's a perfectly legitimate use case.  
> 
> Ok. There's still a worrying bit in nesting lock_sock under
> netdev_lock (ovpn_peer_add -> netdev_lock -> ovpn_peer_add_p2p ->
> unlock_ovpn -> ovpn_socket_release -> lock_sock).

No opinion on socket lock, TBH. It does indeed increase the potential
for hard to trace deadlocks. But I'd think the ordering is intuitive -
netdev lock "feels" heavier than socket lock.