Re: [PATCH v3 1/1] nvme-tcp: wait socket wmem to drain in queue stop

[Sagi Grimberg]

Given that this is a fix - lets rename the patch title to say that.

nvme-tcp: fix possible data corruption caused by premature queue removal 
and I/O failover


On 24/04/2025 19:17, Michael Liang wrote:
> This patch addresses a data corruption issue observed in nvme-tcp during
> testing.
>
> Issue description:
> In an NVMe native multipath setup, when an I/O timeout occurs, all inflight
> I/Os are canceled almost immediately after the kernel socket is shut down.
> These canceled I/Os are reported as host path errors, triggering a failover
> that succeeds on a different path.
>
> However, at this point, the original I/O may still be outstanding in the
> host's network transmission path (e.g., the NIC’s TX queue). From the
> user-space app's perspective, the buffer associated with the I/O is considered
> completed since they're acked on the different path and may be reused for new
> I/O requests.
>
> Because nvme-tcp enables zero-copy by default in the transmission path,
> this can lead to corrupted data being sent to the original target, ultimately
> causing data corruption.
>
> We can reproduce this data corruption by injecting delay on one path and
> triggering i/o timeout.
>
> To prevent this issue, this change ensures that all inflight transmissions are
> fully completed from host's perspective before returning from queue
> stop. To handle concurrent I/O timeout from multiple namespaces under
> the same controller, always wait in queue stop regardless of queue's state.
>
> This aligns with the behavior of queue stopping in other NVMe fabric transports.

We need a "Fixes: " tag, even if it goes all the way to day-0...

> Reviewed-by: Mohamed Khalfella <mkhalfella@xxxxxxxxxxxxxxx>
> Reviewed-by: Randy Jennings <randyj@xxxxxxxxxxxxxxx>
> Signed-off-by: Michael Liang <mliang@xxxxxxxxxxxxxxx>

Please resend, but you can add to your v4
Reviewed-by: Sagi Grimberg <sagi@xxxxxxxxxxx>