Re: [PATCH net v1] net/ipv6: mcast: fix circular locking dependency in __ipv6_dev_mc_inc()

[Wouter Verhelst]

Hi Paolo,

On Thu, Mar 19, 2026 at 01:44:00PM +0100, Paolo Abeni wrote:
> Adding Josef.
> 
> On 3/19/26 4:26 AM, Jakub Kicinski wrote:
> > On Thu, 19 Mar 2026 11:04:24 +0800 Jiayuan Chen wrote:
> >>>> Split mca_alloc() into mca_alloc() + mca_init(): mca_alloc() does the
> >>>> GFP_KERNEL allocation before mc_lock, mca_init() initializes under
> >>>> mc_lock. If the address already exists, the pre-allocated memory is
> >>>> simply freed. Also move inet6_ifmcaddr_notify() outside mc_lock since
> >>>> it also does GFP_KERNEL allocation.  
> >>> Moving the allocation seems fine, but also having to move the
> >>> notification, potentially letting the notification go out of order
> >>> makes me wonder if we aren't better off adding helpers for taking this
> >>> lock which also call memalloc_noio_{save,restore} ?  
> >> Yeah, using memalloc_noio helpers is simpler. I checked and there
> >> are about 18 places taking mc_lock, so having a common mc_lock()/mc_unlock()
> >> wrapper that does the noio save/restore covers them all (if necessary).
> >>
> >> The only thing that feels a bit odd is using memalloc_noio in the networking
> >> subsystem. It makes sense in block/fs to protect itself from recursion.
> > 
> > Totally agree that it feels a bit odd that we have to worry about IO,
> > but unless we can figure out a way to prevent nbd sockets from getting
> > here all our solutions are dealing with noio in networking code :(
> > IMHO it's better to acknowledge this with the explicit memalloc_noio 
> > so future developers don't break things again with a mis-placed
> > allocation.
> 
> I think a problem here is that the nbd socket is still exposed to
> user-space, while in use by the block device. I fear that the more
> syzkaller will learn new tricks, the more we will have to had strange
> noio all around the networking code.
> 
> I *think* we could prevent this kind of races with something alike the
> following:
> - nbd sets a DOIO sk flag on the sockets it uses.
> - the socket layer prevents socketopts()/ioctl() entirely on DOIO sk
> 
> I'm not sure if that could break nbd users, but allowing the user-space
> to mess with the socket used for backing a block device looks very
> dangerous.

I didn't see the rest of the thread, but.

There are two ways of configuring the nbd device, through nbd-client:

- The "old" way has userspace do the initial negotiation, then calls
  NBD_DO_IT on the NBD device with the socket to tell the kernel to go
  ahead and use the socket
- The "new" way has userspace do the initial negotiation, then sends a
  netlink message with the socket to tell the kernel to go ahead and use
  the socket.

So, really, it's the other way around: userspace isn't playing with the
socket, the kernel is playing with a socket that originated in
userspace.

If userspace can be trusted to configure a socket for the kernel, then
surely that shouldn't be a problem? ;-)

(apologies if I didn't understand the problem correctly)

-- 
"I never had a C in history!"
"Yeah, but there was so much less of it when you were my age!"
 -- Joe Brockmeier recounting a conversation with his father, cfgmgmtcamp 2026, Ghent