Re: 回复: Re: [PATCH] bpf: disable lockdep while running BPF on lock_release

From: quanyeyang

Date: Thu Aug 06 2026 - 00:27:29 EST


On Thursday, August 6th, 2026 at AM 6:44, NeilBrown <neilb@xxxxxxxxxxx> wrote:

> So I thought about this some more and came up with this approach which
> might be a good compromise. I builds but I haven't tested it.
> What do you thing?
>
> NeilBrown

Tested it now (PROVE_LOCKING + the syzbot reproducer at the Closes:
link). It fixes the false positive cleanly:

before: "WARNING: possible recursive locking" on rhashtable_bucket,
5 instances during the reproducer's run;
after: no warning; new lockdep complaints.

The subclass layout reads right, and rhashtable.c has the single
mutex_lock(&ht->mutex) (rht_deferred_worker, which you moved to
_nested(1)), so nothing else is left at the old subclass.

One nit: the new field line in your mail shows a stray leading "o"

o struct lock_class_key *lockdep_key;

probably a paste artifact; the actual field is fine.

Thanks for working this through -- reusing the existing per-init-site
key with subclasses is much cleaner than my params suggestion.

quanyeyang