nvme-tcp: i/o errors and stalled host from failure to send command pdus

Jonathan Nicklin jnicklin at blockbridge.com
Thu Sep 1 10:46:11 PDT 2022


nvme_tcp_queue_more() reads queue->mode_requests. So, I supposed
nvme_tcp_queue_request() is an example where queue->more_requests gets
read without the send_mutex? queue_work_on() is conditionalized on this.

Apologies in advance if I'm misunderstanding the code.

On Thu, Sep 1, 2022 at 1:02 PM Sagi Grimberg <sagi at grimberg.me> wrote:
>
>
> > Question: queue->more_requests is updated under a lock. However, not
> > all readers of queue->more_requests acquire the lock. The smp_id/smp_id2
> > values seem to show that the same queue was being processed on
> > different CPUs. Is this a race between the kworker and inline
> > submission?
>
> The entire send path in io_work is wrapped with the send_mutex. Which
> part is not protected with the lock?



More information about the Linux-nvme mailing list