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
