On Mon, Mar 16, 2026 at 08:35:14AM +0000, [email protected] wrote: > > diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c > > index f02254a21585..9923703a1544 100644 > > --- a/kernel/bpf/trampoline.c > > +++ b/kernel/bpf/trampoline.c > > [ ... ] > > > +/* > > + * 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. > > + */ > > +#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]; > > During v1 review, Alexei asked to add a comment explaining both the > pool size of 32 and why per-lock class keys are needed: > > https://lore.kernel.org/bpf/caadnvql_jpe_7a55htn5cyyoxwchahik3+cdeoeurqzauf+...@mail.gmail.com/ > > The comment explains the 32 count (MAX_LOCK_DEPTH limit), but does > it also need to mention why each lock has its own lock_class_key? > Without that, 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.
yep, will add jirka > > > --- > 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/23133791558
