ublksrv_ctrl_del_dev block

[375583810a]

Call Trace:
[ 2780.096864]
[ 2780.096866] __schedule+0x2aa/0x610
[ 2780.096868] schedule+0x63/0x110
[ 2780.096873] ublk_ctrl_uring_cmd+0x12b4/0x146f [ublk_drv]
[ 2780.096877] ? __pfx_autoremove_wake_function+0x10/0x10
[ 2780.096880] io_uring_cmd+0x9d/0x140
[ 2780.096883] io_issue_sqe+0x1b2/0x410
[ 2780.096884] io_wq_submit_work+0x8d/0x2c0
[ 2780.096886] io_worker_handle_work+0x114/0x320
[ 2780.096888] io_wqe_worker+0x132/0x380
[ 2780.096891] ? raw_spin_rq_unlock+0x10/0x40
[ 2780.096893] ? finish_task_switch.isra.0+0x85/0x2a0
[ 2780.096895] ? __pfx_io_wqe_worker+0x10/0x10
[ 2780.096897] ret_from_fork+0x2c/0x50

io_uring=2.3 liburing=2.4 call ublksrv_ctrl_del_dev block,

[375583810a]

but change liburing ver to 2.3 no this bug

[ming1]

but change liburing ver to 2.3 no this bug

Hello,

Thanks for the report.

This kind of issue often means that /dev/ublkcN reference
isn't released. In ublksrv, its FD needs to be closed, and either
the daemon is exit or each queue's io command buffer is unmapped(mmap actually holds one reference of the device).

ublksrv' s CI test actually builds ublksrv against liburing HEAD,
looks not see such report in the whole test done in CI.

https://github.com/ming1/ubdsrv/blob/master/ci/mkosi.build

 git clone git://git.kernel.dk/liburing.git

So can you share your test step and kernel version/ublksrv version? This info should be helpful for figuring out what is wrong with the /dev/ublkcN reference things.

Thanks,
Ming