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

[Nilay Shroff]

On 6/4/26 8:02 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 argument of nvme_tcp_reclassify_socket() from
> 'struct socket *' to 'struct nvme_tcp_queue *' to pass both the socket
> and the keys. Add CONFIG_DEBUG_LOCK_ALLOC guards to nvme_tcp_alloc_queue()
> and nvme_tcp_free_queue() to register and unregister the dynamic keys.
> Additionally, move nvme_tcp_reclassify_socket() inside these guards since
> it's only needed when lockdep is enabled.
> 
> 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>

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