[PATCH 2/2] nvme-tcp: delay nvme_tcp_reclassify_socket()

[Nilay Shroff]

On 9/14/26 1:18 PM, Shin'ichiro Kawasaki wrote:
> From: Eric Dumazet<edumazet at google.com>
> 
> Commit 841aee4d75f1 ("nvme-tcp: lockdep: annotate in-kernel sockets")
> introduced nvme_tcp_reclassify_socket() to resolve a lockdep WARN by
> distinguishing userspace sockets from nvme-tcp sockets. After that, TLS
> encryption support was introduced to nvme-tcp and it added another lock
> dependency on userspace socket handling by tlshd, which resulted in a
> new lockdep WARN. This WARN was hidden by the commit 19bdb70c77d3
> ("nvme-tcp: lockdep: use dynamic lockdep keys per socket instance").
> However, it turned out the commit 19bdb70c77d3 has a bug of lockdep key
> lifetime management, and it is to be reverted by another patch in this
> series. After the revert, the WARN was unveiled and observed at the
> blktests test case nvme/062:
> 
>    WARNING: possible circular locking dependency detected
>    7.3.0-rc2+ #455 Tainted: G        W
>    ------------------------------------------------------
>    tlshd/75867 is trying to acquire lock:
>    ffffffff91ada5e0 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_cache_noprof+0x64/0x6d0
> 
>    but task is already holding lock:
>    ffff888197808258 (sk_lock-AF_INET-NVME){+.+.}-{0:0}, at: do_tcp_setsockopt+0x499/0x26a0
> 
>    which lock already depends on the new lock.
> 
> To fix the lockdep WARN caused by the TLS encryption support, delay the
> reclassification of the nvme-tcp sockets. Currently the reclassification
> happens before the TLS handshake starts, which pulls in the additional
> lock dependencies related to tlshd. Reclassify the sockets after the TLS
> handshake instead, to cut that dependency.
> 
> Link:https://lore.kernel.org/lkml/CANn89i+wnTLC==UnXCpjsS4YxvEfhe5oK0N7fttbqr1zKyqdug@mail.gmail.com/
> Signed-off-by: Eric Dumazet<edumazet at google.com>
> Signed-off-by: Shin'ichiro Kawasaki<shinichiro.kawasaki at wdc.com>

Looks good to me.

Reviewed-by: Nilay Shroff <nilay at linux.ibm.com>