> diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c > index f02254a21585..eb4ea78ff77f 100644 > --- a/kernel/bpf/trampoline.c > +++ b/kernel/bpf/trampoline.c > @@ -30,6 +30,34 @@ static struct hlist_head > trampoline_ip_table[TRAMPOLINE_TABLE_SIZE]; > /* 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 why the pool has 32 locks (MAX_LOCK_DEPTH limit), but could it clarify why each lock needs its own lock_class_key? Without this detail, it's not obvious that distinct keys are needed to avoid lockdep "recursive locking" warnings when trampoline_lock_all() acquires all 32 pool mutexes simultaneously (presumably in following changes). This was raised by [email protected] in v3 review: "Comment explains 32 count but not why per-lock class keys needed; should mention avoiding lockdep recursive locking warnings" https://lore.kernel.org/bpf/31ae46274a3157f2b9840e1a09b2698d1ec0cfd461737ff460c2d3349a9f0...@mail.kernel.org/ The concern was acknowledged with "will add", but the v5 comment still says only "to keep it simple" without addressing the lockdep recursive locking concern. The same issue was raised again in v5: https://lore.kernel.org/bpf/53b3e6cb10e12555d3b1b321eeb4e04a447c707c387568d1e9ef759fb6459...@mail.kernel.org/ > +#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/24598000047
