* [PATCH] rhashtable: use per-init-site lockdep classes for bucket locks
@ 2026-08-01 10:13 quanyeyang via B4 Relay
2026-08-01 11:12 ` NeilBrown
2026-08-14 19:27 ` kernel test robot
0 siblings, 2 replies; 6+ messages in thread
From: quanyeyang via B4 Relay @ 2026-08-01 10:13 UTC (permalink / raw)
To: Thomas Graf, Herbert Xu, Andrew Morton, NeilBrown, David S. Miller
Cc: linux-crypto, linux-kernel, syzbot+ef8d17bae14efb960935, quanyeyang
From: quanyeyang <quanyemostima@gmail.com>
All bucket tables currently share a single lockdep class. This makes
lockdep conflate bucket locks from unrelated rhashtable instances.
A BPF program attached to lock_release can expose this when pidfs
inserts a pid. The tracepoint runs before lockdep removes the pidfs
bucket lock from the task's held-lock stack. Deleting an element from
a BPF RHASH map then acquires a bucket lock belonging to a different
rhashtable. Since both tables use the same class, lockdep reports
possible recursive locking.
Declare a separate bucket lock class key at each rhashtable_init() and
rhltable_init() call site, alongside the mutex class key. Store the
bucket key in struct rhashtable so tables created during resize keep
using the same class.
A targeted reproducer triggers the warning reliably before this change.
After the change, the nested BPF RHASH deletion still executes, but
lockdep no longer reports recursive locking.
Fixes: 149212f07856 ("rhashtable: add lockdep tracking to bucket bit-spin-locks.")
Reported-by: syzbot+ef8d17bae14efb960935@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ef8d17bae14efb960935
Assisted-by: Cursor:GPT-5.6 Sol
Signed-off-by: quanyeyang <quanyemostima@gmail.com>
---
include/linux/rhashtable-types.h | 20 ++++++++++++++------
lib/rhashtable.c | 19 +++++++++++++------
2 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/include/linux/rhashtable-types.h b/include/linux/rhashtable-types.h
index 57c11ec9dc64..4dea91a49ec8 100644
--- a/include/linux/rhashtable-types.h
+++ b/include/linux/rhashtable-types.h
@@ -82,6 +82,7 @@ struct rhashtable_params {
* @mutex: Mutex to protect current/future table swapping
* @lock: Spin lock to protect walker list
* @nelems: Number of elements in table
+ * @bucket_lock_key: Per-init-site lockdep class for bucket bit-locks
*/
struct rhashtable {
struct bucket_table __rcu *tbl;
@@ -94,6 +95,7 @@ struct rhashtable {
struct mutex mutex;
spinlock_t lock;
atomic_t nelems;
+ struct lock_class_key *bucket_lock_key;
#ifdef CONFIG_MEM_ALLOC_PROFILING
struct alloc_tag *alloc_tag;
#endif
@@ -138,23 +140,29 @@ struct rhashtable_iter {
int __rhashtable_init_noprof(struct rhashtable *ht,
const struct rhashtable_params *params,
- struct lock_class_key *key);
+ struct lock_class_key *mutex_key,
+ struct lock_class_key *bucket_key);
#define rhashtable_init_noprof(ht, params) \
({ \
- static struct lock_class_key __key; \
+ static struct lock_class_key __mutex_key; \
+ static struct lock_class_key __bucket_key; \
\
- __rhashtable_init_noprof(ht, params, &__key); \
+ __rhashtable_init_noprof(ht, params, &__mutex_key, \
+ &__bucket_key); \
})
#define rhashtable_init(...) alloc_hooks(rhashtable_init_noprof(__VA_ARGS__))
int __rhltable_init_noprof(struct rhltable *hlt,
const struct rhashtable_params *params,
- struct lock_class_key *key);
+ struct lock_class_key *mutex_key,
+ struct lock_class_key *bucket_key);
#define rhltable_init_noprof(hlt, params) \
({ \
- static struct lock_class_key __key; \
+ static struct lock_class_key __mutex_key; \
+ static struct lock_class_key __bucket_key; \
\
- __rhltable_init_noprof(hlt, params, &__key); \
+ __rhltable_init_noprof(hlt, params, &__mutex_key, \
+ &__bucket_key); \
})
#define rhltable_init(...) alloc_hooks(rhltable_init_noprof(__VA_ARGS__))
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index d459bef245f4..e047ad912f0e 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -189,7 +189,6 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht,
struct bucket_table *tbl = NULL;
size_t size;
int i;
- static struct lock_class_key __key;
tbl = alloc_hooks_tag(ht->alloc_tag,
kvmalloc_node_align_noprof(struct_size(tbl, buckets, nbuckets),
@@ -205,7 +204,12 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht,
if (tbl == NULL)
return NULL;
- lockdep_init_map(&tbl->dep_map, "rhashtable_bucket", &__key, 0);
+ /*
+ * Keep all bucket tables belonging to the same rhashtable in the
+ * per-init-site lock class, including tables created during resize.
+ */
+ lockdep_init_map(&tbl->dep_map, "rhashtable_bucket",
+ ht->bucket_lock_key, 0);
tbl->size = size;
@@ -1162,7 +1166,8 @@ static u32 rhashtable_jhash2(const void *key, u32 length, u32 seed)
*/
int __rhashtable_init_noprof(struct rhashtable *ht,
const struct rhashtable_params *params,
- struct lock_class_key *key)
+ struct lock_class_key *mutex_key,
+ struct lock_class_key *bucket_key)
{
struct bucket_table *tbl;
size_t size;
@@ -1172,7 +1177,8 @@ int __rhashtable_init_noprof(struct rhashtable *ht,
return -EINVAL;
memset(ht, 0, sizeof(*ht));
- mutex_init_with_key(&ht->mutex, key);
+ mutex_init_with_key(&ht->mutex, mutex_key);
+ ht->bucket_lock_key = bucket_key;
spin_lock_init(&ht->lock);
memcpy(&ht->p, params, sizeof(*params));
@@ -1237,11 +1243,12 @@ EXPORT_SYMBOL_GPL(__rhashtable_init_noprof);
*/
int __rhltable_init_noprof(struct rhltable *hlt,
const struct rhashtable_params *params,
- struct lock_class_key *key)
+ struct lock_class_key *mutex_key,
+ struct lock_class_key *bucket_key)
{
int err;
- err = __rhashtable_init_noprof(&hlt->ht, params, key);
+ err = __rhashtable_init_noprof(&hlt->ht, params, mutex_key, bucket_key);
hlt->ht.rhlist = true;
return err;
}
---
base-commit: 0131b508c0e2489eac6e121135988f6eeb716f19
change-id: 20260801-fix-rhashtable-bucket-lockdep-95e25abebeea
Best regards,
--
quanyeyang <quanyemostima@gmail.com>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] rhashtable: use per-init-site lockdep classes for bucket locks 2026-08-01 10:13 [PATCH] rhashtable: use per-init-site lockdep classes for bucket locks quanyeyang via B4 Relay @ 2026-08-01 11:12 ` NeilBrown 2026-08-02 10:33 ` Quanye Yang 2026-08-14 19:27 ` kernel test robot 1 sibling, 1 reply; 6+ messages in thread From: NeilBrown @ 2026-08-01 11:12 UTC (permalink / raw) To: quanyemostima Cc: Thomas Graf, Herbert Xu, Andrew Morton, David S. Miller, linux-crypto, linux-kernel, syzbot+ef8d17bae14efb960935, quanyeyang On Sat, 01 Aug 2026, quanyemostima@gmail.com wrote: > From: quanyeyang <quanyemostima@gmail.com> > > All bucket tables currently share a single lockdep class. This makes > lockdep conflate bucket locks from unrelated rhashtable instances. > > A BPF program attached to lock_release can expose this when pidfs > inserts a pid. The tracepoint runs before lockdep removes the pidfs > bucket lock from the task's held-lock stack. Deleting an element from > a BPF RHASH map then acquires a bucket lock belonging to a different > rhashtable. Since both tables use the same class, lockdep reports > possible recursive locking. This seems like a band-aid rather than a proper fix. Surely attaching a BPF program to lock_release() has potential for causing all sorts of lockdep related problems. Any lock that the BPF program takes can trigger something, and I find it unlikely that rhashtable is the only part of BPF code that takes a lock. Maybe the tracepoint needs to disable lockdep while the BPF handler is running, or something like that. But I would need a much stronger argument before I could be happy with this patch. NeilBrown > > Declare a separate bucket lock class key at each rhashtable_init() and > rhltable_init() call site, alongside the mutex class key. Store the > bucket key in struct rhashtable so tables created during resize keep > using the same class. > > A targeted reproducer triggers the warning reliably before this change. > After the change, the nested BPF RHASH deletion still executes, but > lockdep no longer reports recursive locking. > > Fixes: 149212f07856 ("rhashtable: add lockdep tracking to bucket bit-spin-locks.") > Reported-by: syzbot+ef8d17bae14efb960935@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=ef8d17bae14efb960935 > Assisted-by: Cursor:GPT-5.6 Sol > Signed-off-by: quanyeyang <quanyemostima@gmail.com> > --- > include/linux/rhashtable-types.h | 20 ++++++++++++++------ > lib/rhashtable.c | 19 +++++++++++++------ > 2 files changed, 27 insertions(+), 12 deletions(-) > > diff --git a/include/linux/rhashtable-types.h b/include/linux/rhashtable-types.h > index 57c11ec9dc64..4dea91a49ec8 100644 > --- a/include/linux/rhashtable-types.h > +++ b/include/linux/rhashtable-types.h > @@ -82,6 +82,7 @@ struct rhashtable_params { > * @mutex: Mutex to protect current/future table swapping > * @lock: Spin lock to protect walker list > * @nelems: Number of elements in table > + * @bucket_lock_key: Per-init-site lockdep class for bucket bit-locks > */ > struct rhashtable { > struct bucket_table __rcu *tbl; > @@ -94,6 +95,7 @@ struct rhashtable { > struct mutex mutex; > spinlock_t lock; > atomic_t nelems; > + struct lock_class_key *bucket_lock_key; > #ifdef CONFIG_MEM_ALLOC_PROFILING > struct alloc_tag *alloc_tag; > #endif > @@ -138,23 +140,29 @@ struct rhashtable_iter { > > int __rhashtable_init_noprof(struct rhashtable *ht, > const struct rhashtable_params *params, > - struct lock_class_key *key); > + struct lock_class_key *mutex_key, > + struct lock_class_key *bucket_key); > #define rhashtable_init_noprof(ht, params) \ > ({ \ > - static struct lock_class_key __key; \ > + static struct lock_class_key __mutex_key; \ > + static struct lock_class_key __bucket_key; \ > \ > - __rhashtable_init_noprof(ht, params, &__key); \ > + __rhashtable_init_noprof(ht, params, &__mutex_key, \ > + &__bucket_key); \ > }) > #define rhashtable_init(...) alloc_hooks(rhashtable_init_noprof(__VA_ARGS__)) > > int __rhltable_init_noprof(struct rhltable *hlt, > const struct rhashtable_params *params, > - struct lock_class_key *key); > + struct lock_class_key *mutex_key, > + struct lock_class_key *bucket_key); > #define rhltable_init_noprof(hlt, params) \ > ({ \ > - static struct lock_class_key __key; \ > + static struct lock_class_key __mutex_key; \ > + static struct lock_class_key __bucket_key; \ > \ > - __rhltable_init_noprof(hlt, params, &__key); \ > + __rhltable_init_noprof(hlt, params, &__mutex_key, \ > + &__bucket_key); \ > }) > #define rhltable_init(...) alloc_hooks(rhltable_init_noprof(__VA_ARGS__)) > > diff --git a/lib/rhashtable.c b/lib/rhashtable.c > index d459bef245f4..e047ad912f0e 100644 > --- a/lib/rhashtable.c > +++ b/lib/rhashtable.c > @@ -189,7 +189,6 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, > struct bucket_table *tbl = NULL; > size_t size; > int i; > - static struct lock_class_key __key; > > tbl = alloc_hooks_tag(ht->alloc_tag, > kvmalloc_node_align_noprof(struct_size(tbl, buckets, nbuckets), > @@ -205,7 +204,12 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, > if (tbl == NULL) > return NULL; > > - lockdep_init_map(&tbl->dep_map, "rhashtable_bucket", &__key, 0); > + /* > + * Keep all bucket tables belonging to the same rhashtable in the > + * per-init-site lock class, including tables created during resize. > + */ > + lockdep_init_map(&tbl->dep_map, "rhashtable_bucket", > + ht->bucket_lock_key, 0); > > tbl->size = size; > > @@ -1162,7 +1166,8 @@ static u32 rhashtable_jhash2(const void *key, u32 length, u32 seed) > */ > int __rhashtable_init_noprof(struct rhashtable *ht, > const struct rhashtable_params *params, > - struct lock_class_key *key) > + struct lock_class_key *mutex_key, > + struct lock_class_key *bucket_key) > { > struct bucket_table *tbl; > size_t size; > @@ -1172,7 +1177,8 @@ int __rhashtable_init_noprof(struct rhashtable *ht, > return -EINVAL; > > memset(ht, 0, sizeof(*ht)); > - mutex_init_with_key(&ht->mutex, key); > + mutex_init_with_key(&ht->mutex, mutex_key); > + ht->bucket_lock_key = bucket_key; > spin_lock_init(&ht->lock); > memcpy(&ht->p, params, sizeof(*params)); > > @@ -1237,11 +1243,12 @@ EXPORT_SYMBOL_GPL(__rhashtable_init_noprof); > */ > int __rhltable_init_noprof(struct rhltable *hlt, > const struct rhashtable_params *params, > - struct lock_class_key *key) > + struct lock_class_key *mutex_key, > + struct lock_class_key *bucket_key) > { > int err; > > - err = __rhashtable_init_noprof(&hlt->ht, params, key); > + err = __rhashtable_init_noprof(&hlt->ht, params, mutex_key, bucket_key); > hlt->ht.rhlist = true; > return err; > } > > --- > base-commit: 0131b508c0e2489eac6e121135988f6eeb716f19 > change-id: 20260801-fix-rhashtable-bucket-lockdep-95e25abebeea > > Best regards, > -- > quanyeyang <quanyemostima@gmail.com> > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] rhashtable: use per-init-site lockdep classes for bucket locks 2026-08-01 11:12 ` NeilBrown @ 2026-08-02 10:33 ` Quanye Yang 2026-08-03 2:00 ` NeilBrown 0 siblings, 1 reply; 6+ messages in thread From: Quanye Yang @ 2026-08-02 10:33 UTC (permalink / raw) To: NeilBrown Cc: Thomas Graf, Herbert Xu, Andrew Morton, David S. Miller, linux-crypto, linux-kernel, syzbot+ef8d17bae14efb960935 On Sat, Aug 01, 2026 at 07:12:00PM +0000, NeilBrown wrote: > This seems like a band-aid rather than a proper fix. > > Surely attaching a BPF program to lock_release() has potential for > causing all sorts of lockdep related problems. Any lock that the BPF > program takes can trigger something, and I find it unlikely that > rhashtable is the only part of BPF code that takes a lock. > > Maybe the tracepoint needs to disable lockdep while the BPF handler is > running, or something like that. > > But I would need a much stronger argument before I could be happy with > this patch. Thanks for the review. I agree that attaching BPF to lock_release() is a sharp edge: the tracepoint runs before __lock_release(), so the lock is still on the lockdep held stack, and any lock taken by the BPF program becomes a dependency edge. Whether that instrumentation path should be isolated from lockdep is a broader question, and I don't claim this patch solves it. But the syzbot warning at hand is not BPF-specific. It is a false positive from modeling every rhashtable bucket lock with one global lock_class_key. Different rhashtable instances have different physical bitlocks; nesting them is not recursive locking of the same lock. I can reproduce the same "possible recursive locking detected" without any BPF / lock tracepoint: 1. init two tables at distinct rhashtable_init() call sites (ht_a, ht_b) 2. prefill so the insert path walks a non-empty bucket chain 3. in ht_a's obj_cmpfn (called under ht_a's bucket bitlock), call rhashtable_lookup_insert_key() on ht_b That is enough to hit the warning on an unpatched kernel. So disabling lockdep around the BPF handler would only silence one trigger for this class-modeling bug; it would not fix the underlying incorrect lock class sharing, and it would also hide real lock-order problems on that path (including the callback-under-bucket-lock cases that 149212f07856 wanted lockdep to see). The per-init-site bucket key follows the same approach as 060d4e94b8d4 did for ht->mutex: keep one class per init site (and across resize of that table via SINGLE_DEPTH_NESTING), rather than one class for the entire kernel. Happy to share the small local reproducer if that helps. On Sat, Aug 1, 2026 at 7:12 PM NeilBrown <neilb@ownmail.net> wrote: > > On Sat, 01 Aug 2026, quanyemostima@gmail.com wrote: > > From: quanyeyang <quanyemostima@gmail.com> > > > > All bucket tables currently share a single lockdep class. This makes > > lockdep conflate bucket locks from unrelated rhashtable instances. > > > > A BPF program attached to lock_release can expose this when pidfs > > inserts a pid. The tracepoint runs before lockdep removes the pidfs > > bucket lock from the task's held-lock stack. Deleting an element from > > a BPF RHASH map then acquires a bucket lock belonging to a different > > rhashtable. Since both tables use the same class, lockdep reports > > possible recursive locking. > > This seems like a band-aid rather than a proper fix. > > Surely attaching a BPF program to lock_release() has potential for > causing all sorts of lockdep related problems. Any lock that the BPF > program takes can trigger something, and I find it unlikely that > rhashtable is the only part of BPF code that takes a lock. > > Maybe the tracepoint needs to disable lockdep while the BPF handler is > running, or something like that. > > But I would need a much stronger argument before I could be happy with > this patch. > > NeilBrown > > > > > > Declare a separate bucket lock class key at each rhashtable_init() and > > rhltable_init() call site, alongside the mutex class key. Store the > > bucket key in struct rhashtable so tables created during resize keep > > using the same class. > > > > A targeted reproducer triggers the warning reliably before this change. > > After the change, the nested BPF RHASH deletion still executes, but > > lockdep no longer reports recursive locking. > > > > Fixes: 149212f07856 ("rhashtable: add lockdep tracking to bucket bit-spin-locks.") > > Reported-by: syzbot+ef8d17bae14efb960935@syzkaller.appspotmail.com > > Closes: https://syzkaller.appspot.com/bug?extid=ef8d17bae14efb960935 > > Assisted-by: Cursor:GPT-5.6 Sol > > Signed-off-by: quanyeyang <quanyemostima@gmail.com> > > --- > > include/linux/rhashtable-types.h | 20 ++++++++++++++------ > > lib/rhashtable.c | 19 +++++++++++++------ > > 2 files changed, 27 insertions(+), 12 deletions(-) > > > > diff --git a/include/linux/rhashtable-types.h b/include/linux/rhashtable-types.h > > index 57c11ec9dc64..4dea91a49ec8 100644 > > --- a/include/linux/rhashtable-types.h > > +++ b/include/linux/rhashtable-types.h > > @@ -82,6 +82,7 @@ struct rhashtable_params { > > * @mutex: Mutex to protect current/future table swapping > > * @lock: Spin lock to protect walker list > > * @nelems: Number of elements in table > > + * @bucket_lock_key: Per-init-site lockdep class for bucket bit-locks > > */ > > struct rhashtable { > > struct bucket_table __rcu *tbl; > > @@ -94,6 +95,7 @@ struct rhashtable { > > struct mutex mutex; > > spinlock_t lock; > > atomic_t nelems; > > + struct lock_class_key *bucket_lock_key; > > #ifdef CONFIG_MEM_ALLOC_PROFILING > > struct alloc_tag *alloc_tag; > > #endif > > @@ -138,23 +140,29 @@ struct rhashtable_iter { > > > > int __rhashtable_init_noprof(struct rhashtable *ht, > > const struct rhashtable_params *params, > > - struct lock_class_key *key); > > + struct lock_class_key *mutex_key, > > + struct lock_class_key *bucket_key); > > #define rhashtable_init_noprof(ht, params) \ > > ({ \ > > - static struct lock_class_key __key; \ > > + static struct lock_class_key __mutex_key; \ > > + static struct lock_class_key __bucket_key; \ > > \ > > - __rhashtable_init_noprof(ht, params, &__key); \ > > + __rhashtable_init_noprof(ht, params, &__mutex_key, \ > > + &__bucket_key); \ > > }) > > #define rhashtable_init(...) alloc_hooks(rhashtable_init_noprof(__VA_ARGS__)) > > > > int __rhltable_init_noprof(struct rhltable *hlt, > > const struct rhashtable_params *params, > > - struct lock_class_key *key); > > + struct lock_class_key *mutex_key, > > + struct lock_class_key *bucket_key); > > #define rhltable_init_noprof(hlt, params) \ > > ({ \ > > - static struct lock_class_key __key; \ > > + static struct lock_class_key __mutex_key; \ > > + static struct lock_class_key __bucket_key; \ > > \ > > - __rhltable_init_noprof(hlt, params, &__key); \ > > + __rhltable_init_noprof(hlt, params, &__mutex_key, \ > > + &__bucket_key); \ > > }) > > #define rhltable_init(...) alloc_hooks(rhltable_init_noprof(__VA_ARGS__)) > > > > diff --git a/lib/rhashtable.c b/lib/rhashtable.c > > index d459bef245f4..e047ad912f0e 100644 > > --- a/lib/rhashtable.c > > +++ b/lib/rhashtable.c > > @@ -189,7 +189,6 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, > > struct bucket_table *tbl = NULL; > > size_t size; > > int i; > > - static struct lock_class_key __key; > > > > tbl = alloc_hooks_tag(ht->alloc_tag, > > kvmalloc_node_align_noprof(struct_size(tbl, buckets, nbuckets), > > @@ -205,7 +204,12 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, > > if (tbl == NULL) > > return NULL; > > > > - lockdep_init_map(&tbl->dep_map, "rhashtable_bucket", &__key, 0); > > + /* > > + * Keep all bucket tables belonging to the same rhashtable in the > > + * per-init-site lock class, including tables created during resize. > > + */ > > + lockdep_init_map(&tbl->dep_map, "rhashtable_bucket", > > + ht->bucket_lock_key, 0); > > > > tbl->size = size; > > > > @@ -1162,7 +1166,8 @@ static u32 rhashtable_jhash2(const void *key, u32 length, u32 seed) > > */ > > int __rhashtable_init_noprof(struct rhashtable *ht, > > const struct rhashtable_params *params, > > - struct lock_class_key *key) > > + struct lock_class_key *mutex_key, > > + struct lock_class_key *bucket_key) > > { > > struct bucket_table *tbl; > > size_t size; > > @@ -1172,7 +1177,8 @@ int __rhashtable_init_noprof(struct rhashtable *ht, > > return -EINVAL; > > > > memset(ht, 0, sizeof(*ht)); > > - mutex_init_with_key(&ht->mutex, key); > > + mutex_init_with_key(&ht->mutex, mutex_key); > > + ht->bucket_lock_key = bucket_key; > > spin_lock_init(&ht->lock); > > memcpy(&ht->p, params, sizeof(*params)); > > > > @@ -1237,11 +1243,12 @@ EXPORT_SYMBOL_GPL(__rhashtable_init_noprof); > > */ > > int __rhltable_init_noprof(struct rhltable *hlt, > > const struct rhashtable_params *params, > > - struct lock_class_key *key) > > + struct lock_class_key *mutex_key, > > + struct lock_class_key *bucket_key) > > { > > int err; > > > > - err = __rhashtable_init_noprof(&hlt->ht, params, key); > > + err = __rhashtable_init_noprof(&hlt->ht, params, mutex_key, bucket_key); > > hlt->ht.rhlist = true; > > return err; > > } > > > > --- > > base-commit: 0131b508c0e2489eac6e121135988f6eeb716f19 > > change-id: 20260801-fix-rhashtable-bucket-lockdep-95e25abebeea > > > > Best regards, > > -- > > quanyeyang <quanyemostima@gmail.com> > > > > > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] rhashtable: use per-init-site lockdep classes for bucket locks 2026-08-02 10:33 ` Quanye Yang @ 2026-08-03 2:00 ` NeilBrown 2026-08-03 14:38 ` Quanye Yang 0 siblings, 1 reply; 6+ messages in thread From: NeilBrown @ 2026-08-03 2:00 UTC (permalink / raw) To: Quanye Yang Cc: Thomas Graf, Herbert Xu, Andrew Morton, David S. Miller, linux-crypto, linux-kernel, syzbot+ef8d17bae14efb960935 On Sun, 02 Aug 2026, Quanye Yang wrote: > On Sat, Aug 01, 2026 at 07:12:00PM +0000, NeilBrown wrote: > > This seems like a band-aid rather than a proper fix. > > > > Surely attaching a BPF program to lock_release() has potential for > > causing all sorts of lockdep related problems. Any lock that the BPF > > program takes can trigger something, and I find it unlikely that > > rhashtable is the only part of BPF code that takes a lock. > > > > Maybe the tracepoint needs to disable lockdep while the BPF handler is > > running, or something like that. > > > > But I would need a much stronger argument before I could be happy with > > this patch. > > Thanks for the review. > > I agree that attaching BPF to lock_release() is a sharp edge: the > tracepoint runs before __lock_release(), so the lock is still on the > lockdep held stack, and any lock taken by the BPF program becomes a > dependency edge. Whether that instrumentation path should be isolated > from lockdep is a broader question, and I don't claim this patch solves > it. > > But the syzbot warning at hand is not BPF-specific. It is a false > positive from modeling every rhashtable bucket lock with one global > lock_class_key. Different rhashtable instances have different physical > bitlocks; nesting them is not recursive locking of the same lock. This is common practice in the kernel. All dentries for all filesystems have a d_lock with the same lock_class. All block devices have a bd_holder_lock mutex with the same lock_class. All kobjects have a list_lock with the same lock_class. > > I can reproduce the same "possible recursive locking detected" without > any BPF / lock tracepoint: > > 1. init two tables at distinct rhashtable_init() call sites (ht_a, ht_b) > 2. prefill so the insert path walks a non-empty bucket chain > 3. in ht_a's obj_cmpfn (called under ht_a's bucket bitlock), call > rhashtable_lookup_insert_key() on ht_b Yes you *can* do that, but why *would* you do that? The obj_cmpfn is meant to be an idempotent compare function. We make no particular promises about when it will be called. So making a change to anything in that function is ill-advised at best. I don't think we have any interest in making change which would allow an obj_cmpfn() to make changes to a different rhashtable. > > That is enough to hit the warning on an unpatched kernel. So disabling > lockdep around the BPF handler would only silence one trigger for this > class-modeling bug; it would not fix the underlying incorrect lock class > sharing, and it would also hide real lock-order problems on that path > (including the callback-under-bucket-lock cases that 149212f07856 wanted > lockdep to see). I think the main reason we added the lockdep tracking was to justify that switching from spinlocks to bitlock didn't lose anything important. It wouldn't be completely inappropriate to take a lock in an obj_cmpfn, but I wouldn't normally expect it. > > The per-init-site bucket key follows the same approach as 060d4e94b8d4 > did for ht->mutex: keep one class per init site (and across resize of > that table via SINGLE_DEPTH_NESTING), rather than one class for the > entire kernel. Hmmm.. I think that patch might have been a poor choice. Commit 09ae540e1d5c ("rhashtable: drop ht->mutex in rhashtable_free_and_destroy()") landed about the same time and removed the problem instead of hiding it. NeilBrown > > Happy to share the small local reproducer if that helps. > > On Sat, Aug 1, 2026 at 7:12 PM NeilBrown <neilb@ownmail.net> wrote: > > > > On Sat, 01 Aug 2026, quanyemostima@gmail.com wrote: > > > From: quanyeyang <quanyemostima@gmail.com> > > > > > > All bucket tables currently share a single lockdep class. This makes > > > lockdep conflate bucket locks from unrelated rhashtable instances. > > > > > > A BPF program attached to lock_release can expose this when pidfs > > > inserts a pid. The tracepoint runs before lockdep removes the pidfs > > > bucket lock from the task's held-lock stack. Deleting an element from > > > a BPF RHASH map then acquires a bucket lock belonging to a different > > > rhashtable. Since both tables use the same class, lockdep reports > > > possible recursive locking. > > > > This seems like a band-aid rather than a proper fix. > > > > Surely attaching a BPF program to lock_release() has potential for > > causing all sorts of lockdep related problems. Any lock that the BPF > > program takes can trigger something, and I find it unlikely that > > rhashtable is the only part of BPF code that takes a lock. > > > > Maybe the tracepoint needs to disable lockdep while the BPF handler is > > running, or something like that. > > > > But I would need a much stronger argument before I could be happy with > > this patch. > > > > NeilBrown > > > > > > > > > > Declare a separate bucket lock class key at each rhashtable_init() and > > > rhltable_init() call site, alongside the mutex class key. Store the > > > bucket key in struct rhashtable so tables created during resize keep > > > using the same class. > > > > > > A targeted reproducer triggers the warning reliably before this change. > > > After the change, the nested BPF RHASH deletion still executes, but > > > lockdep no longer reports recursive locking. > > > > > > Fixes: 149212f07856 ("rhashtable: add lockdep tracking to bucket bit-spin-locks.") > > > Reported-by: syzbot+ef8d17bae14efb960935@syzkaller.appspotmail.com > > > Closes: https://syzkaller.appspot.com/bug?extid=ef8d17bae14efb960935 > > > Assisted-by: Cursor:GPT-5.6 Sol > > > Signed-off-by: quanyeyang <quanyemostima@gmail.com> > > > --- > > > include/linux/rhashtable-types.h | 20 ++++++++++++++------ > > > lib/rhashtable.c | 19 +++++++++++++------ > > > 2 files changed, 27 insertions(+), 12 deletions(-) > > > > > > diff --git a/include/linux/rhashtable-types.h b/include/linux/rhashtable-types.h > > > index 57c11ec9dc64..4dea91a49ec8 100644 > > > --- a/include/linux/rhashtable-types.h > > > +++ b/include/linux/rhashtable-types.h > > > @@ -82,6 +82,7 @@ struct rhashtable_params { > > > * @mutex: Mutex to protect current/future table swapping > > > * @lock: Spin lock to protect walker list > > > * @nelems: Number of elements in table > > > + * @bucket_lock_key: Per-init-site lockdep class for bucket bit-locks > > > */ > > > struct rhashtable { > > > struct bucket_table __rcu *tbl; > > > @@ -94,6 +95,7 @@ struct rhashtable { > > > struct mutex mutex; > > > spinlock_t lock; > > > atomic_t nelems; > > > + struct lock_class_key *bucket_lock_key; > > > #ifdef CONFIG_MEM_ALLOC_PROFILING > > > struct alloc_tag *alloc_tag; > > > #endif > > > @@ -138,23 +140,29 @@ struct rhashtable_iter { > > > > > > int __rhashtable_init_noprof(struct rhashtable *ht, > > > const struct rhashtable_params *params, > > > - struct lock_class_key *key); > > > + struct lock_class_key *mutex_key, > > > + struct lock_class_key *bucket_key); > > > #define rhashtable_init_noprof(ht, params) \ > > > ({ \ > > > - static struct lock_class_key __key; \ > > > + static struct lock_class_key __mutex_key; \ > > > + static struct lock_class_key __bucket_key; \ > > > \ > > > - __rhashtable_init_noprof(ht, params, &__key); \ > > > + __rhashtable_init_noprof(ht, params, &__mutex_key, \ > > > + &__bucket_key); \ > > > }) > > > #define rhashtable_init(...) alloc_hooks(rhashtable_init_noprof(__VA_ARGS__)) > > > > > > int __rhltable_init_noprof(struct rhltable *hlt, > > > const struct rhashtable_params *params, > > > - struct lock_class_key *key); > > > + struct lock_class_key *mutex_key, > > > + struct lock_class_key *bucket_key); > > > #define rhltable_init_noprof(hlt, params) \ > > > ({ \ > > > - static struct lock_class_key __key; \ > > > + static struct lock_class_key __mutex_key; \ > > > + static struct lock_class_key __bucket_key; \ > > > \ > > > - __rhltable_init_noprof(hlt, params, &__key); \ > > > + __rhltable_init_noprof(hlt, params, &__mutex_key, \ > > > + &__bucket_key); \ > > > }) > > > #define rhltable_init(...) alloc_hooks(rhltable_init_noprof(__VA_ARGS__)) > > > > > > diff --git a/lib/rhashtable.c b/lib/rhashtable.c > > > index d459bef245f4..e047ad912f0e 100644 > > > --- a/lib/rhashtable.c > > > +++ b/lib/rhashtable.c > > > @@ -189,7 +189,6 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, > > > struct bucket_table *tbl = NULL; > > > size_t size; > > > int i; > > > - static struct lock_class_key __key; > > > > > > tbl = alloc_hooks_tag(ht->alloc_tag, > > > kvmalloc_node_align_noprof(struct_size(tbl, buckets, nbuckets), > > > @@ -205,7 +204,12 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, > > > if (tbl == NULL) > > > return NULL; > > > > > > - lockdep_init_map(&tbl->dep_map, "rhashtable_bucket", &__key, 0); > > > + /* > > > + * Keep all bucket tables belonging to the same rhashtable in the > > > + * per-init-site lock class, including tables created during resize. > > > + */ > > > + lockdep_init_map(&tbl->dep_map, "rhashtable_bucket", > > > + ht->bucket_lock_key, 0); > > > > > > tbl->size = size; > > > > > > @@ -1162,7 +1166,8 @@ static u32 rhashtable_jhash2(const void *key, u32 length, u32 seed) > > > */ > > > int __rhashtable_init_noprof(struct rhashtable *ht, > > > const struct rhashtable_params *params, > > > - struct lock_class_key *key) > > > + struct lock_class_key *mutex_key, > > > + struct lock_class_key *bucket_key) > > > { > > > struct bucket_table *tbl; > > > size_t size; > > > @@ -1172,7 +1177,8 @@ int __rhashtable_init_noprof(struct rhashtable *ht, > > > return -EINVAL; > > > > > > memset(ht, 0, sizeof(*ht)); > > > - mutex_init_with_key(&ht->mutex, key); > > > + mutex_init_with_key(&ht->mutex, mutex_key); > > > + ht->bucket_lock_key = bucket_key; > > > spin_lock_init(&ht->lock); > > > memcpy(&ht->p, params, sizeof(*params)); > > > > > > @@ -1237,11 +1243,12 @@ EXPORT_SYMBOL_GPL(__rhashtable_init_noprof); > > > */ > > > int __rhltable_init_noprof(struct rhltable *hlt, > > > const struct rhashtable_params *params, > > > - struct lock_class_key *key) > > > + struct lock_class_key *mutex_key, > > > + struct lock_class_key *bucket_key) > > > { > > > int err; > > > > > > - err = __rhashtable_init_noprof(&hlt->ht, params, key); > > > + err = __rhashtable_init_noprof(&hlt->ht, params, mutex_key, bucket_key); > > > hlt->ht.rhlist = true; > > > return err; > > > } > > > > > > --- > > > base-commit: 0131b508c0e2489eac6e121135988f6eeb716f19 > > > change-id: 20260801-fix-rhashtable-bucket-lockdep-95e25abebeea > > > > > > Best regards, > > > -- > > > quanyeyang <quanyemostima@gmail.com> > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] rhashtable: use per-init-site lockdep classes for bucket locks 2026-08-03 2:00 ` NeilBrown @ 2026-08-03 14:38 ` Quanye Yang 0 siblings, 0 replies; 6+ messages in thread From: Quanye Yang @ 2026-08-03 14:38 UTC (permalink / raw) To: NeilBrown Cc: Thomas Graf, Herbert Xu, Andrew Morton, David S. Miller, linux-crypto, linux-kernel, syzbot+ef8d17bae14efb960935 On Mon, 03 Aug 2026, NeilBrown wrote: > This is common practice in the kernel. > All dentries for all filesystems have a d_lock with the same lock_class. > All block devices have a bd_holder_lock mutex with the same lock_class. > All kobjects have a list_lock with the same lock_class. Fair enough — that matches d_lock / bd_holder_lock / kobject list_lock. The per-init-site split was the wrong tool here. > The obj_cmpfn is meant to be an idempotent compare function. > We make no particular promises about when it will be called. Right — the obj_cmpfn reproducer isn't a realistic case to shape the lock modeling around. > Commit 09ae540e1d5c ... removed the problem instead of hiding it. That's the takeaway: remove the problem rather than paper over the class modeling. So I'm dropping this rhashtable patch, and taking the direction you suggested — disable lockdep around the BPF handler on lock_release — as a separate RFC: https://lore.kernel.org/all/20260803-fix-lock-tracepoint-bpf-lockdep-v1-1-91fb7afb526a@gmail.com/ Thanks for the review. quanyeyang On Mon, Aug 3, 2026 at 10:00 AM NeilBrown <neilb@ownmail.net> wrote: > > On Sun, 02 Aug 2026, Quanye Yang wrote: > > On Sat, Aug 01, 2026 at 07:12:00PM +0000, NeilBrown wrote: > > > This seems like a band-aid rather than a proper fix. > > > > > > Surely attaching a BPF program to lock_release() has potential for > > > causing all sorts of lockdep related problems. Any lock that the BPF > > > program takes can trigger something, and I find it unlikely that > > > rhashtable is the only part of BPF code that takes a lock. > > > > > > Maybe the tracepoint needs to disable lockdep while the BPF handler is > > > running, or something like that. > > > > > > But I would need a much stronger argument before I could be happy with > > > this patch. > > > > Thanks for the review. > > > > I agree that attaching BPF to lock_release() is a sharp edge: the > > tracepoint runs before __lock_release(), so the lock is still on the > > lockdep held stack, and any lock taken by the BPF program becomes a > > dependency edge. Whether that instrumentation path should be isolated > > from lockdep is a broader question, and I don't claim this patch solves > > it. > > > > But the syzbot warning at hand is not BPF-specific. It is a false > > positive from modeling every rhashtable bucket lock with one global > > lock_class_key. Different rhashtable instances have different physical > > bitlocks; nesting them is not recursive locking of the same lock. > > This is common practice in the kernel. > All dentries for all filesystems have a d_lock with the same lock_class. > All block devices have a bd_holder_lock mutex with the same lock_class. > All kobjects have a list_lock with the same lock_class. > > > > > I can reproduce the same "possible recursive locking detected" without > > any BPF / lock tracepoint: > > > > 1. init two tables at distinct rhashtable_init() call sites (ht_a, ht_b) > > 2. prefill so the insert path walks a non-empty bucket chain > > 3. in ht_a's obj_cmpfn (called under ht_a's bucket bitlock), call > > rhashtable_lookup_insert_key() on ht_b > > Yes you *can* do that, but why *would* you do that? > The obj_cmpfn is meant to be an idempotent compare function. > We make no particular promises about when it will be called. > So making a change to anything in that function is ill-advised at best. > I don't think we have any interest in making change which would allow > an obj_cmpfn() to make changes to a different rhashtable. > > > > > That is enough to hit the warning on an unpatched kernel. So disabling > > lockdep around the BPF handler would only silence one trigger for this > > class-modeling bug; it would not fix the underlying incorrect lock class > > sharing, and it would also hide real lock-order problems on that path > > (including the callback-under-bucket-lock cases that 149212f07856 wanted > > lockdep to see). > > I think the main reason we added the lockdep tracking was to justify > that switching from spinlocks to bitlock didn't lose anything important. > It wouldn't be completely inappropriate to take a lock in an obj_cmpfn, > but I wouldn't normally expect it. > > > > > The per-init-site bucket key follows the same approach as 060d4e94b8d4 > > did for ht->mutex: keep one class per init site (and across resize of > > that table via SINGLE_DEPTH_NESTING), rather than one class for the > > entire kernel. > > Hmmm.. I think that patch might have been a poor choice. > > Commit 09ae540e1d5c ("rhashtable: drop ht->mutex in rhashtable_free_and_destroy()") > > landed about the same time and removed the problem instead of hiding it. > > NeilBrown > > > > > > Happy to share the small local reproducer if that helps. > > > > On Sat, Aug 1, 2026 at 7:12 PM NeilBrown <neilb@ownmail.net> wrote: > > > > > > On Sat, 01 Aug 2026, quanyemostima@gmail.com wrote: > > > > From: quanyeyang <quanyemostima@gmail.com> > > > > > > > > All bucket tables currently share a single lockdep class. This makes > > > > lockdep conflate bucket locks from unrelated rhashtable instances. > > > > > > > > A BPF program attached to lock_release can expose this when pidfs > > > > inserts a pid. The tracepoint runs before lockdep removes the pidfs > > > > bucket lock from the task's held-lock stack. Deleting an element from > > > > a BPF RHASH map then acquires a bucket lock belonging to a different > > > > rhashtable. Since both tables use the same class, lockdep reports > > > > possible recursive locking. > > > > > > This seems like a band-aid rather than a proper fix. > > > > > > Surely attaching a BPF program to lock_release() has potential for > > > causing all sorts of lockdep related problems. Any lock that the BPF > > > program takes can trigger something, and I find it unlikely that > > > rhashtable is the only part of BPF code that takes a lock. > > > > > > Maybe the tracepoint needs to disable lockdep while the BPF handler is > > > running, or something like that. > > > > > > But I would need a much stronger argument before I could be happy with > > > this patch. > > > > > > NeilBrown > > > > > > > > > > > > > > Declare a separate bucket lock class key at each rhashtable_init() and > > > > rhltable_init() call site, alongside the mutex class key. Store the > > > > bucket key in struct rhashtable so tables created during resize keep > > > > using the same class. > > > > > > > > A targeted reproducer triggers the warning reliably before this change. > > > > After the change, the nested BPF RHASH deletion still executes, but > > > > lockdep no longer reports recursive locking. > > > > > > > > Fixes: 149212f07856 ("rhashtable: add lockdep tracking to bucket bit-spin-locks.") > > > > Reported-by: syzbot+ef8d17bae14efb960935@syzkaller.appspotmail.com > > > > Closes: https://syzkaller.appspot.com/bug?extid=ef8d17bae14efb960935 > > > > Assisted-by: Cursor:GPT-5.6 Sol > > > > Signed-off-by: quanyeyang <quanyemostima@gmail.com> > > > > --- > > > > include/linux/rhashtable-types.h | 20 ++++++++++++++------ > > > > lib/rhashtable.c | 19 +++++++++++++------ > > > > 2 files changed, 27 insertions(+), 12 deletions(-) > > > > > > > > diff --git a/include/linux/rhashtable-types.h b/include/linux/rhashtable-types.h > > > > index 57c11ec9dc64..4dea91a49ec8 100644 > > > > --- a/include/linux/rhashtable-types.h > > > > +++ b/include/linux/rhashtable-types.h > > > > @@ -82,6 +82,7 @@ struct rhashtable_params { > > > > * @mutex: Mutex to protect current/future table swapping > > > > * @lock: Spin lock to protect walker list > > > > * @nelems: Number of elements in table > > > > + * @bucket_lock_key: Per-init-site lockdep class for bucket bit-locks > > > > */ > > > > struct rhashtable { > > > > struct bucket_table __rcu *tbl; > > > > @@ -94,6 +95,7 @@ struct rhashtable { > > > > struct mutex mutex; > > > > spinlock_t lock; > > > > atomic_t nelems; > > > > + struct lock_class_key *bucket_lock_key; > > > > #ifdef CONFIG_MEM_ALLOC_PROFILING > > > > struct alloc_tag *alloc_tag; > > > > #endif > > > > @@ -138,23 +140,29 @@ struct rhashtable_iter { > > > > > > > > int __rhashtable_init_noprof(struct rhashtable *ht, > > > > const struct rhashtable_params *params, > > > > - struct lock_class_key *key); > > > > + struct lock_class_key *mutex_key, > > > > + struct lock_class_key *bucket_key); > > > > #define rhashtable_init_noprof(ht, params) \ > > > > ({ \ > > > > - static struct lock_class_key __key; \ > > > > + static struct lock_class_key __mutex_key; \ > > > > + static struct lock_class_key __bucket_key; \ > > > > \ > > > > - __rhashtable_init_noprof(ht, params, &__key); \ > > > > + __rhashtable_init_noprof(ht, params, &__mutex_key, \ > > > > + &__bucket_key); \ > > > > }) > > > > #define rhashtable_init(...) alloc_hooks(rhashtable_init_noprof(__VA_ARGS__)) > > > > > > > > int __rhltable_init_noprof(struct rhltable *hlt, > > > > const struct rhashtable_params *params, > > > > - struct lock_class_key *key); > > > > + struct lock_class_key *mutex_key, > > > > + struct lock_class_key *bucket_key); > > > > #define rhltable_init_noprof(hlt, params) \ > > > > ({ \ > > > > - static struct lock_class_key __key; \ > > > > + static struct lock_class_key __mutex_key; \ > > > > + static struct lock_class_key __bucket_key; \ > > > > \ > > > > - __rhltable_init_noprof(hlt, params, &__key); \ > > > > + __rhltable_init_noprof(hlt, params, &__mutex_key, \ > > > > + &__bucket_key); \ > > > > }) > > > > #define rhltable_init(...) alloc_hooks(rhltable_init_noprof(__VA_ARGS__)) > > > > > > > > diff --git a/lib/rhashtable.c b/lib/rhashtable.c > > > > index d459bef245f4..e047ad912f0e 100644 > > > > --- a/lib/rhashtable.c > > > > +++ b/lib/rhashtable.c > > > > @@ -189,7 +189,6 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, > > > > struct bucket_table *tbl = NULL; > > > > size_t size; > > > > int i; > > > > - static struct lock_class_key __key; > > > > > > > > tbl = alloc_hooks_tag(ht->alloc_tag, > > > > kvmalloc_node_align_noprof(struct_size(tbl, buckets, nbuckets), > > > > @@ -205,7 +204,12 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, > > > > if (tbl == NULL) > > > > return NULL; > > > > > > > > - lockdep_init_map(&tbl->dep_map, "rhashtable_bucket", &__key, 0); > > > > + /* > > > > + * Keep all bucket tables belonging to the same rhashtable in the > > > > + * per-init-site lock class, including tables created during resize. > > > > + */ > > > > + lockdep_init_map(&tbl->dep_map, "rhashtable_bucket", > > > > + ht->bucket_lock_key, 0); > > > > > > > > tbl->size = size; > > > > > > > > @@ -1162,7 +1166,8 @@ static u32 rhashtable_jhash2(const void *key, u32 length, u32 seed) > > > > */ > > > > int __rhashtable_init_noprof(struct rhashtable *ht, > > > > const struct rhashtable_params *params, > > > > - struct lock_class_key *key) > > > > + struct lock_class_key *mutex_key, > > > > + struct lock_class_key *bucket_key) > > > > { > > > > struct bucket_table *tbl; > > > > size_t size; > > > > @@ -1172,7 +1177,8 @@ int __rhashtable_init_noprof(struct rhashtable *ht, > > > > return -EINVAL; > > > > > > > > memset(ht, 0, sizeof(*ht)); > > > > - mutex_init_with_key(&ht->mutex, key); > > > > + mutex_init_with_key(&ht->mutex, mutex_key); > > > > + ht->bucket_lock_key = bucket_key; > > > > spin_lock_init(&ht->lock); > > > > memcpy(&ht->p, params, sizeof(*params)); > > > > > > > > @@ -1237,11 +1243,12 @@ EXPORT_SYMBOL_GPL(__rhashtable_init_noprof); > > > > */ > > > > int __rhltable_init_noprof(struct rhltable *hlt, > > > > const struct rhashtable_params *params, > > > > - struct lock_class_key *key) > > > > + struct lock_class_key *mutex_key, > > > > + struct lock_class_key *bucket_key) > > > > { > > > > int err; > > > > > > > > - err = __rhashtable_init_noprof(&hlt->ht, params, key); > > > > + err = __rhashtable_init_noprof(&hlt->ht, params, mutex_key, bucket_key); > > > > hlt->ht.rhlist = true; > > > > return err; > > > > } > > > > > > > > --- > > > > base-commit: 0131b508c0e2489eac6e121135988f6eeb716f19 > > > > change-id: 20260801-fix-rhashtable-bucket-lockdep-95e25abebeea > > > > > > > > Best regards, > > > > -- > > > > quanyeyang <quanyemostima@gmail.com> > > > > > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] rhashtable: use per-init-site lockdep classes for bucket locks 2026-08-01 10:13 [PATCH] rhashtable: use per-init-site lockdep classes for bucket locks quanyeyang via B4 Relay 2026-08-01 11:12 ` NeilBrown @ 2026-08-14 19:27 ` kernel test robot 1 sibling, 0 replies; 6+ messages in thread From: kernel test robot @ 2026-08-14 19:27 UTC (permalink / raw) To: quanyeyang via B4 Relay, Thomas Graf, Herbert Xu, Andrew Morton, NeilBrown, David S. Miller Cc: oe-kbuild-all, Linux Memory Management List, netdev, linux-crypto, linux-kernel, syzbot+ef8d17bae14efb960935, quanyeyang Hi quanyeyang, kernel test robot noticed the following build warnings: [auto build test WARNING on 0131b508c0e2489eac6e121135988f6eeb716f19] url: https://github.com/intel-lab-lkp/linux/commits/quanyeyang-via-B4-Relay/rhashtable-use-per-init-site-lockdep-classes-for-bucket-locks/20260815-014140 base: 0131b508c0e2489eac6e121135988f6eeb716f19 patch link: https://lore.kernel.org/r/20260801-fix-rhashtable-bucket-lockdep-v1-1-15a0f8ae094c%40gmail.com patch subject: [PATCH] rhashtable: use per-init-site lockdep classes for bucket locks config: alpha-allmodconfig (https://download.01.org/0day-ci/archive/20260815/202608150357.9LheVOQg-lkp@intel.com/config) compiler: alpha-linux-gcc (GCC) 16.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260815/202608150357.9LheVOQg-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202608150357.9LheVOQg-lkp@intel.com/ All warnings (new ones prefixed by >>): >> Warning: lib/rhashtable.c:1170 function parameter 'mutex_key' not described in '__rhashtable_init' >> Warning: lib/rhashtable.c:1170 function parameter 'bucket_key' not described in '__rhashtable_init' Warning: lib/rhashtable.c:1170 expecting prototype for rhashtable_init(). Prototype was for __rhashtable_init() instead >> Warning: lib/rhashtable.c:1247 function parameter 'mutex_key' not described in '__rhltable_init' >> Warning: lib/rhashtable.c:1247 function parameter 'bucket_key' not described in '__rhltable_init' Warning: lib/rhashtable.c:1247 expecting prototype for rhltable_init(). Prototype was for __rhltable_init() instead -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-08-14 19:28 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-08-01 10:13 [PATCH] rhashtable: use per-init-site lockdep classes for bucket locks quanyeyang via B4 Relay 2026-08-01 11:12 ` NeilBrown 2026-08-02 10:33 ` Quanye Yang 2026-08-03 2:00 ` NeilBrown 2026-08-03 14:38 ` Quanye Yang 2026-08-14 19:27 ` kernel test robot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®