Re: [PATCH v4 3/3] nvme-tcp: parallelize I/O queue allocation and startup

[Martin Belanger <martin.nvme.dev@gmail.com>]

On 9/22/26 16:07, Surabhi Gogte wrote:
 > Similar to commit 2a8513091d2f ("nvme-rdma: parallelize I/O queue
 > allocation and startup"), refactor nvme tcp I/O queue setup to use async
 > API, combining allocation and startup into a single parallel operation
 > per queue. This reduces connection and reconnection setup time when
 > there are delays in establishing connections, which is especially
 > important for high-core-count hosts.
[...]

Hi Surabhi,

This patch breaks NVMe/TCP connects with TLS. This is a different bug
from the pf_cache_lock one that Shin'ichiro reported.

Test: one VM with 4 CPUs, nvmet-tcp on 127.0.0.1 with tsas tls1.3, a
connect with --tls and 4 I/O queues, and tlshd at upstream commit
a0bd51d.

- Linus master 6b4b543fa187: 14 of 20 connects fail.
- Same tree with this patch reverted: 20 of 20 connects pass.
- Same tree with Daniel's pf_cache_lock fix [1]: 22 of 40 and 17 of 40
   connects fail.

On each failed connect, one I/O queue logs:

   nvme nvme0: queue 4: TLS handshake complete, error -110

The tlshd that runs for the target logs:

   failed to search 'psk' key 'NVMe0R01 <hostnqn> <subnqn>'
   gnutls: Error in password/key file. (-31)

and closes the connection. The tlshd that runs for the host then gets
GNUTLS_E_PREMATURE_TERMINATION, which it reports to the kernel as
ETIMEDOUT. The other queues use the same PSK, and their handshakes
succeed. blktests nvme/062 and nvme/063 fail the same way.

I can share the reproducer script.

[1] 
https://lore.kernel.org/all/20261014-nvme-fabrics-isolcpu-v1-1-355156be27b2@kernel.org/

Martin