linux-kernel - Re: lock classes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZoLnsZ47vJNSuxa5@boqun-archlinux>
Date: Mon, 1 Jul 2024 10:30:25 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: ahmed Ehab <bottaawesome633@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: lock classes

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