Re: [bug report] blktests nvme/tcp nvme/060 hang

["Maurizio Lombardi" <mlombard@bsdbackstore.eu>]

On Wed Aug 6, 2025 at 3:57 AM CEST, Yi Zhang wrote:
> Hello
> I hit this issue when I was running blktests nvme/tcp nvme/060 on the
> latest linux-block/for-next with rt enabled, please help check it and
> let me know if you need any info/testing for it, thanks.
>
> [  390.474378] Call trace:
> [  390.476813]  __switch_to+0x1d8/0x330 (T)
> [  390.480731]  __schedule+0x860/0x1c30
> [  390.484297]  schedule_rtlock+0x30/0x70
> [  390.488037]  rtlock_slowlock_locked+0x464/0xf60
> [  390.492559]  rt_read_lock+0x2bc/0x3e0
> [  390.496211]  nvmet_tcp_listen_data_ready+0x3c/0x118 [nvmet_tcp]
> [  390.502125]  nvmet_tcp_data_ready+0x88/0x198 [nvmet_tcp]

I think that the problem is due to the fact that nvmet_tcp_data_ready()
calls the queue->data_ready() callback with the sk_callback_lock
locked.
The data_ready callback points to nvmet_tcp_listen_data_ready()
which tries to lock the same sk_callback_lock, hence the deadlock.

Maybe it can be fixed by deferring the call to queue->data_ready() by
using a workqueue.

Maurizio