[PATCH 2/2] nvme-tcp: lockdep: use dynamic lockdep keys per socket instance

[Nilay Shroff]

On 5/30/26 10:50 AM, Shin'ichiro Kawasaki wrote:
> When NVMe-TCP controller setup and teardown are repeated with lockdep
> enabled, lockdep reports false positives WARN for the following locks:
> 
>    1) &q->elevator_lock        : IO scheduler change context
>    2) &q->q_usage_counter(io)  : SCSI disk probe context
>    3) fs_reclaim               : CPU hotplug bring-up context
>    4) cpu_hotplug_lock         : socket establishment context
>    5) sk_lock-AF_INET-NVME     : MQ sched dispatch context for the socket
>    6) set->srcu                : NVMe controller delete context
> 
> The lockdep WARN was observed by running blktests test case nvme/005 for
> tcp transport on v7.1-rc1 kernel with a patch. Refer to the Link tag for
> the details of the WARN.
> 
> This is a false positive because lockdep confuses lock 4) (socket
> establishment) with lock 5) (socket in use) for different socket
> instances. The locks belong to different sockets, but lockdep treats
> them as the same due to shared static lockdep keys.
> 
> Fix this by using dynamically allocated lockdep keys per socket instance
> instead of static keys nvme_tcp_sk_key[] and nvme_tcp_slock_key[]. Add
> nvme_tcp_sk_key and nvme_tcp_slock_key fields to struct nvme_tcp_queue
> and pass them to sock_lock_init_class_and_name() for proper lockdep
> tracking. Change the arguement of nvme_tcp_reclassify_socket() from
> 'struct socket *' to 'struct nvme_tcp_queue *' to pass both the socket
> and the keys.
> 
> Link:https://lore.kernel.org/linux-nvme/afB5syZbUrppgsDQ@shinmob/
> Suggested-by: Nilay Shroff<nilay at linux.ibm.com>
> Signed-off-by: Shin'ichiro Kawasaki<shinichiro.kawasaki at wdc.com>
> ---
>   drivers/nvme/host/tcp.c | 32 +++++++++++++++++++++-----------
>   1 file changed, 21 insertions(+), 11 deletions(-)

Looks good to me.
Reviewed-by: Nilay Shroff <nilay at linux.ibm.com>