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,
Tao
