2026年10月20日 21:03, "Tao Cui" <[email protected]
mailto:[email protected]?to=%22Tao%20Cui%22%20%3Ccui.tao%40linux.dev%3E > 写到:
>
> Hi Jackie,
>
> 在 2026/10/19 16:42, Jackie Liu 写道:
>
> >
> > Commit 8b428f42f3ed ("nbd: fix lockdep deadlock warning") drops
> > config_lock around blk_mq_update_nr_hw_queues(). The initial checks for a
> > running device and NBD_FLAG_CAN_MULTI_CONN can become stale while the
> > lock is dropped.
> >
> > Two NBD_DO_IT callers can both pass the PID check. After the first caller
> > starts the device, the loser overwrites nbd->pid before failing to create
> > the existing sysfs pid attribute. Concurrent NBD_SET_SOCK or NBD_SET_FLAGS
> > can also leave multiple connections without NBD_FLAG_CAN_MULTI_CONN,
> > which the queue-count retry does not validate.
> >
> > Recheck both conditions after reacquiring config_lock. Reject an already
> > started device with EBUSY, and reject unsupported multiple connections
> > with EINVAL before retrying the queue update or starting receive workers.
> >
> > Each fix is followed by its regression test. The tests prime the hardware
> > queue count before each attempt and use socket pairs, so no external NBD
> > server is needed. They require CAP_SYS_ADMIN, at least two online CPUs
> > and unused NBD devices.
> >
> Tested this series on top of next-20261019 (x86_64 KVM guest, 8 vCPUs),
> building and running the new selftests in-guest with nbd loaded as a
> module (nbds_max=4 max_part=0).
>
> On the unpatched kernel both bugs reproduce at round 1: the losing
> NBD_DO_IT caller exits with errno=17 (EEXIST) and /sys/block/nbdX/pid
> reports the loser's pid, and nbd_multi_conn flags both the socket-added
> and flags-changed variants ("invalid second receiver").
>
> With the series applied, nbd_pid_race and nbd_multi_conn pass 100
> rounds per case with seeds 123 and 456 - every round rejected with
> EBUSY/EINVAL, no regressions, dmesg clean.
>
> Tested-by: Tao Cui <[email protected]>
Thanks for test.
--
Jackie Liu
>
> Thanks,
> Tao
>
