[PATCH V3 0/2] nvmet-tcp: fix receive path error handling and state machine

[Maurizio Lombardi]

On Wed Mar 18, 2026 at 1:24 AM CET, Chaitanya Kulkarni wrote:
> On 3/16/26 07:39, Maurizio Lombardi wrote:
>> Patch 1 fixes a potential issue where network data could be read into an
>> uninitialized iterator. Currently, nvmet_tcp_build_pdu_iovec() returns void,
>> meaning callers are unaware if an out-of-bounds PDU length or offset triggers
>> an early return. Consequently, callers blindly overwrite the queue state to
>> NVMET_TCP_RECV_DATA. This patch modifies the function to return an error code,
>> shifting the handling responsibility to the callers to ensure proper socket
>> teardown.
>>
>> Patch 2 cleans up redundant, localized calls to nvmet_tcp_fatal_error() scattered
>> across the receive path. It delegates the responsibility of executing the fatal
>> error function to the top-level caller by bubbling up the error codes.
>>
>> V3: remove nvmet_tcp_fatal_error(), fold it into nvmet_tcp_socket_error()
>>
>> V2: some cosmetic changes to Patch 1, no functional changes.
>>
>> Maurizio Lombardi (2):
>>    nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers
>>    nvmet-tcp: remove redundant calls to nvmet_tcp_fatal_error()
>>
>>   drivers/nvme/target/tcp.c | 88 ++++++++++++++++-----------------------
>>   1 file changed, 36 insertions(+), 52 deletions(-)
>>
> Assuming that you have ran block test on this series with nvme_trtype=tcp
> and this series is passing without any problem.

Yes, Yi Zhang did run the blktests against this patchset

The only problem he reported is a circular locking
warning in the host driver that I think is due to the bug here:

https://lore.kernel.org/linux-nvme/f5065c2c-e30d-418d-8c7a-723e958b54c1@nvidia.com/T/#mb3a8789682514d5f63b711703d32fd6bd197bcec

No other issues were detected.

Thanks,
Maurizio