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

On Thursday, August 6th, 2026 at AM 6:44, NeilBrown <[email protected]> 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