On Tue, Feb 24, 2026 at 4:27 AM Jiri Olsa <[email protected]> wrote:
>
> nope, the rfc had workaround for lockdep ;-)
>
> +#ifdef CONFIG_LOCKDEP
> + mutex_init_with_key(&tr->mutex, &__lockdep_no_track__);
> +#else
The only user of lockdep_set_notrack_class() was removed from the tree.
We shouldn't introduce new special cases.
> but I overlooked lockdep config for this version
>
> > MAX_LOCK_DEPTH is indeed 48.
> >
> > See fs/configfs/inode.c and default_group_class.
> > It does:
> > lockdep_set_class(&inode->i_rwsem,
> > &default_group_class[depth - 1]);
> >
> > the idea here is that the number of lockdep keys doesn't have
> > to be equal to the actual number of mutexes.
>
> I see, thanks for the pointer
>
> >
> > I guess we can keep a total of 32 mutexes to avoid making it too fancy.
> > Please add a comment explaining 32 and why it needs lockdep_key.
>
> ok
>
> >
> > I thought declaring all mutexes as static will avoid the need for the key,
> > but DEFINE_MUTEX doesn't support an array.
> > So since we need a loop anyway to init mutex and the key,
> > let's keep kmalloc_array() above. Which is now renamed to kmalloc_objs()
> > after 7.0-rc1.
>
> I don't mind either way, meanwhile I used this version:
>
> static struct {
> struct mutex mutex;
> struct lock_class_key key;
> } trampoline_locks[TRAMPOLINE_LOCKS_TABLE_SIZE];
>
> for (i = 0; i < TRAMPOLINE_LOCKS_TABLE_SIZE; i++)
> __mutex_init(&trampoline_locks[i].mutex, "trampoline_lock",
> &trampoline_locks[i].key);
works for me.
