> diff --git a/include/linux/bpf.h b/include/linux/bpf.h > --- a/include/linux/bpf.h > +++ b/include/linux/bpf.h
[ ... ] > diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c > --- a/kernel/bpf/trampoline.c > +++ b/kernel/bpf/trampoline.c > @@ -30,6 +30,34 @@ #define TRAMPOLINE_TABLE_SIZE (1 << TRAMPOLINE_HASH_BITS) > /* serializes access to trampoline tables */ > static DEFINE_MUTEX(trampoline_mutex); > > +/* > + * We keep 32 trampoline locks (5 bits) in the pool, because there is > + * 48 (MAX_LOCK_DEPTH) locks limit allowed to be simultaneously held > + * by task. Each lock has its own lockdep key to keep it simple. > + */ The comment explains the 32 count (MAX_LOCK_DEPTH limit), but should it also explain why each lock has its own lock_class_key? Without that explanation, it is not obvious that distinct keys are required to avoid lockdep "recursive locking" warnings when trampoline_lock_all() acquires all 32 pool mutexes simultaneously. This was raised by [email protected] in v3 review: https://lore.kernel.org/bpf/31ae46274a3157f2b9840e1a09b2698d1ec0cfd461737ff460c2d3349a9f0...@mail.kernel.org/ The author acknowledged it with "will add", but the current comment only says "to keep it simple" without addressing the recursive locking concern. > +#define TRAMPOLINE_LOCKS_BITS 5 > +#define TRAMPOLINE_LOCKS_TABLE_SIZE (1 << TRAMPOLINE_LOCKS_BITS) > + > +static struct { > + struct mutex mutex; > + struct lock_class_key key; > +} trampoline_locks[TRAMPOLINE_LOCKS_TABLE_SIZE]; [ ... ] --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24583317711
