[PATCH] lockdep: Fix subclass resource leak in lockdep_unregister_key()

[PATCH] lockdep: Fix subclass resource leak in lockdep_unregister_key()

[Nilay Shroff]

When a dynamic lock key is unregistered using lockdep_unregister_key(),
lockdep routes the cleanup sequence through __lockdep_free_key_range()
with a hardcoded size of 1.

This layout model assumes that a dynamic key only occupies its base
registration address (subclass 0). However, when a lock utilizes
nested acquisitions—either implicitly via networking paths (e.g.,
bh_lock_sock_nested() passing SINGLE_DEPTH_NESTING) or explicitly via
mutex_lock_nested()—lockdep calculates virtual class tracking nodes
using pointer math offsets:

    Virtual Class Pointer = Base Address of Key + Subclass Index

Because the unregister range size is strictly constrained to 1, lockdep
completely skips evaluating adjacent virtual subclass slots (key + 1
through key + 7). Consequently, when dynamic structures (such as per-
queue network sockets) are repeatedly created, teardowned, and allocated
at fresh memory blocks, the subclass /1 structures and their historical
dependency chains are permanently orphaned in the global graph. Over
prolonged runtime and frequent reconnect loops, this asymmetry leads to
the absolute exhaustion of MAX_LOCKDEP_CHAIN_HLOCKS.

Fix this by instructing lockdep_unregister_key() to look ahead across
the entire valid subclass allocation block range
(MAX_LOCKDEP_SUBCLASSES), ensuring that all related subclass matrix
definitions are completely zapped alongside the primary key.

Cc: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reported-by: Geliang Tang <geliang@kernel.org>
Tested-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
---
 kernel/locking/lockdep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 2d4c5bab5af8..490904bee63e 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -6606,7 +6606,7 @@ void lockdep_unregister_key(struct lock_class_key *key)
 	WARN_ON_ONCE(!found && debug_locks);
 	if (found) {
 		pf = get_pending_free();
-		__lockdep_free_key_range(pf, key, 1);
+		__lockdep_free_key_range(pf, key, MAX_LOCKDEP_SUBCLASSES);
 		need_callback = prepare_call_rcu_zapped(pf);
 		nr_dynamic_keys--;
 	}
-- 
2.53.0

Re: [PATCH] lockdep: Fix subclass resource leak in lockdep_unregister_key()

[Waiman Long]

On 7/19/26 11:20 AM, Nilay Shroff wrote:
> When a dynamic lock key is unregistered using lockdep_unregister_key(),
> lockdep routes the cleanup sequence through __lockdep_free_key_range()
> with a hardcoded size of 1.
>
> This layout model assumes that a dynamic key only occupies its base
> registration address (subclass 0). However, when a lock utilizes
> nested acquisitions—either implicitly via networking paths (e.g.,
> bh_lock_sock_nested() passing SINGLE_DEPTH_NESTING) or explicitly via
> mutex_lock_nested()—lockdep calculates virtual class tracking nodes
> using pointer math offsets:
>
>      Virtual Class Pointer = Base Address of Key + Subclass Index
>
> Because the unregister range size is strictly constrained to 1, lockdep
> completely skips evaluating adjacent virtual subclass slots (key + 1
> through key + 7). Consequently, when dynamic structures (such as per-
> queue network sockets) are repeatedly created, teardowned, and allocated
> at fresh memory blocks, the subclass /1 structures and their historical
> dependency chains are permanently orphaned in the global graph. Over
> prolonged runtime and frequent reconnect loops, this asymmetry leads to
> the absolute exhaustion of MAX_LOCKDEP_CHAIN_HLOCKS.
>
> Fix this by instructing lockdep_unregister_key() to look ahead across
> the entire valid subclass allocation block range
> (MAX_LOCKDEP_SUBCLASSES), ensuring that all related subclass matrix
> definitions are completely zapped alongside the primary key.
>
> Cc: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> Reported-by: Geliang Tang <geliang@kernel.org>
> Tested-by: Geliang Tang <geliang@kernel.org>
> Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
> ---
>   kernel/locking/lockdep.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 2d4c5bab5af8..490904bee63e 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -6606,7 +6606,7 @@ void lockdep_unregister_key(struct lock_class_key *key)
>   	WARN_ON_ONCE(!found && debug_locks);
>   	if (found) {
>   		pf = get_pending_free();
> -		__lockdep_free_key_range(pf, key, 1);
> +		__lockdep_free_key_range(pf, key, MAX_LOCKDEP_SUBCLASSES);
>   		need_callback = prepare_call_rcu_zapped(pf);
>   		nr_dynamic_keys--;
>   	}

I think you should add

Fixes: 108c14858b9e ("locking/lockdep: Add support for dynamic keys")

Other than that,
Reviewed-by: Waiman Long <longman@redhat.com>