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

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

On Wed Aug 6, 2025 at 8:16 AM CEST, Maurizio Lombardi wrote:
> 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.
>

Ops sorry they are two read locks, the real problem then is that
something is holding the write lock.

Maurizio