From: Nilay Shroff <nilay@linux.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Boqun Feng <boqun@kernel.org>, Waiman Long <longman@redhat.com>,
linux-kernel@vger.kernel.org
Cc: Nilay Shroff <nilay@linux.ibm.com>,
"Shin'ichiro Kawasaki" <shinichiro.kawasaki@wdc.com>,
Geliang Tang <geliang@kernel.org>
Subject: [PATCH] lockdep: Fix subclass resource leak in lockdep_unregister_key()
Date: Sun, 19 Jul 2026 20:50:03 +0530 [thread overview]
Message-ID: <20260719152015.237188-1-nilay@linux.ibm.com> (raw)
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
next reply other threads:[~2026-07-19 15:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-19 15:20 Nilay Shroff [this message]
2026-07-19 16:52 ` [PATCH] lockdep: Fix subclass resource leak in lockdep_unregister_key() Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260719152015.237188-1-nilay@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=boqun@kernel.org \
--cc=geliang@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=shinichiro.kawasaki@wdc.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.