Re: lock classes

[Boqun Feng]

On Mon, Jul 01, 2024 at 09:20:02AM -0700, Paul E. McKenney wrote:

Thanks, Paul.

> On Mon, Jul 01, 2024 at 03:52:44AM +0300, ahmed Ehab wrote:
> > Hello sir,
> > I am working on a bug reported by syzkaller
> > https://syzkaller.appspot.com/bug?extid=d4200fc83fa03a684c6e . I am getting
> > 2 classes with the same key but different address for the name(different
> > name pointer but same content). The problem is that this info seems to be
> > persisted in the vmlinux itself. Is there any place where I can read about
> > how lock classes are persisted or something?

You could start with code that initializes lockdep_map (which is
corresponding to one lock instance), for this case, it's the
init_rwsem(), and the name & key are linked to the lockdep_map in
lockdep_init_map_type(). Eventually, usually at the first time a lock
instance is used, it will register the lock class, where lockdep
allocates a lock class and store the addresses of the key and name into
it.

So the problem here could be the string literals (i.e. the name
"&ei->i_data_sem") got instanced twice.

Regards,
Boqun

> 
> Hello, Ahmed,
> 
> Adding Boqun and the list on CC in case others have better advice.
> 
> One possibility is that there is a lockdep_set_class_and_name() call
> that is separating out locks that would by default be in the same
> class.  See the use of this function in the rcu_init_one() function in
> kernel/rcu/tree.c for one example use, in this case to create separate
> lock classes for each level of the rcu_node tree.
> 
> There are a number of similar functions, including lockdep_set_class()
> and lockdep_set_class_and_subclass().  These guys might well duplicate
> the name, but I have never used them.  Me, I encode the level into
> the name in order to have better lockdep diagnostics, but that is not
> always practical.
> 
> 							Thanx, Paul