On Thu, Feb 26, 2026 at 05:40:26PM +0000, Pedro Falcato wrote:

+Cc netdev, block, nbd people

On Thu, Feb 26, 2026 at 06:54:27AM -0800, syzbot wrote:
<snip>

quoted

Chain exists of:
  fs_reclaim --> k-sk_lock-AF_INET6 --> &mm->mmap_lock

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  rlock(&mm->mmap_lock);
                               lock(k-sk_lock-AF_INET6);
                               lock(&mm->mmap_lock);
  lock(fs_reclaim);

 *** DEADLOCK ***

2 locks held by syz.3.3387/17804:
 #0: ffffffff905e2228 (br_ioctl_mutex){+.+.}-{4:4}, at: br_ioctl_call+0x34/0xa0 net/socket.c:1225
 #1: ffff88807ad4b440 (&mm->mmap_lock){++++}-{4:4}, at: mmap_read_trylock include/linux/mmap_lock.h:611 [inline]
 #1: ffff88807ad4b440 (&mm->mmap_lock){++++}-{4:4}, at: get_mmap_lock_carefully mm/mmap_lock.c:441 [inline]
 #1: ffff88807ad4b440 (&mm->mmap_lock){++++}-{4:4}, at: lock_mm_and_find_vma+0x35/0x6f0 mm/mmap_lock.c:501

It looks to me like the issue is:
 setsockopt(nbd_sock) -> takes sk_lock -> copy_from_user -> page fault ->
   mmap_lock -> allocation needs reclaim -> fs_reclaim -> fs does IO -> nbd
   grabs sk_lock -> deadlock

Another funny case that came to me just now:
sendmsg(nbd_sock) -> lock_sock(nbd_sock) -> tcp_sendmsg_locked(nbd_sock) ->
copy_from_user() -> if VMA is backed by file on nbd bdev -> ... ->
lock_sock(nbd_sock)

Right? Is there something extremely crucial that I'm missing?

-- 
Pedro