blk_mq holds set->srcu while queuing and running requests.  The kTLS
software send path takes ctx->tx_lock.  lockdep knows that tx_lock
nests under elevator_lock which then waits on srcu, so an inline
send from that path under TLS triggers circular locking.

Skip the inline send optimization for TLS queues so the send runs
from the workqueue instead.  The same workqueue already retries TLS
sends on write-space notifications.  Plain TCP keeps the inline path.

Fixes: be8e82caa685 ("nvme-tcp: enable TLS handshake upcall")
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Signed-off-by: Xixin Liu <liuxixin@kylinos.cn>
---
 drivers/nvme/host/tcp.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index c0fe8cfb7229..22741570fb7f 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -415,8 +415,14 @@ static inline void nvme_tcp_queue_request(struct nvme_tcp_request *req,
 	 * if we're the first on the send_list and we can try to send
 	 * directly, otherwise queue io_work. Also, only do that if we
 	 * are on the same cpu, so we don't introduce contention.
+	 *
+	 * TLS kTLS send takes ctx->tx_lock while blk_mq holds set->srcu.
+	 * lockdep reports circular locking via elevator_lock.  Defer TLS
+	 * sends to the io workqueue instead of inline from this path.
 	 */
 	if (queue->io_cpu == raw_smp_processor_id() &&
+	    !nvme_tcp_queue_tls(queue) &&
 	    empty && mutex_trylock(&queue->send_mutex)) {
 		nvme_tcp_send_all(queue);
 		mutex_unlock(&queue->send_mutex);

-- 
2.53.0

On Wed, Aug 19, 2026 at 08:50:00AM +0800, Xixin Liu wrote:
> blk_mq holds set->srcu while queuing and running requests.  The kTLS
> software send path takes ctx->tx_lock.  lockdep knows that tx_lock
> nests under elevator_lock which then waits on srcu, so an inline
> send from that path under TLS triggers circular locking.
> 
> Skip the inline send optimization for TLS queues so the send runs
> from the workqueue instead.  The same workqueue already retries TLS
> sends on write-space notifications.  Plain TCP keeps the inline path.

Thanks, applied to nvme-7.3.

For future, could you please send new patches as new threads separate
from the discussion that spawned them? You can use "Link:" tags for
prior discussion if you want to keep it, but this interleaving and
changing subjects in the same thread is a bit unpleasant for tracking
purposes.