Re: [PATCH v4 1/2] locking/lockdep: Forcing subclasses to have same name pointer as their parent class

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ahmed,

Sorry I was missing some points on title and changelog, please see below
and refer to Documentation/process/maintainer-tip.rst:

The title needs to be something like:

	locking/lockdep: Avoid creating new name string literals in lockdep_set_subclass()

the title and the changlog needs to be in imperative mode.

On Mon, Jul 15, 2024 at 04:26:37PM +0300, botta633 wrote:
> From: Ahmed Ehab <bottaawesome633@xxxxxxxxx>
> 
> Preventing lockdep_set_subclass from creating a new instance of the


Same here, s/Preventing/Prevent, and when you reference a function, you
want to do "lockdep_set_subclass()" instead of "lockdep_set_subclass".


Besides, overall, you want to structure your changelog as follow:

Syzbot reports a problem that a warning will be triggered while
searching a lock class in look_up_lock_class().

// ^ the problem statement

The cause of the issue is that instead of the existing name of a
lock class, a new name (a string literal) is created and used by
lockdep_set_subclass(), and this results in two lock classes with the
same key but different address of the names, and a WARN_ONCE() is
triggered because of that in look_up_lock_class().

// ^ the analysis of the problem, you can merge the above two into one
// paragraph if that works for you.

To fix this, change lockdep_set_subclass() to use the existing name
instead of a new one. As a result no new name will be created by
lockdep_set_subclass(), hence the warning is avoided.

// ^ the fix.


Please send a new version if these make sense to you. The patch #2 also
needs some changes in the title and changelog, but since that's adding
a new test instead of fixing an issue, you could just write something
like:

Add a test case to ensure that no new name string literal will be
created in lockdep_set_subclass(), otherwise a warning will be triggered
in look_up_lock_class(). Add this to catch the problem in the future.


Thanks!

Regards,
Boqun

> string literal. Hence, we will always have the same class->name among
> parent and subclasses. This prevents kernel panics when looking up a
> lock class while comparing class locks and class names.
> 
> Reported-by: <syzbot+7f4a6f7f7051474e40ad@xxxxxxxxxxxxxxxxxxxxxxxxx>
> Fixes: de8f5e4f2dc1f ("lockdep: Introduce wait-type checks")
> Cc: <stable@xxxxxxxxxxxxxxx>
> Signed-off-by: Ahmed Ehab <bottaawesome633@xxxxxxxxx>
> ---
> v3->v4:
>     - Fixed subject line truncation.
> 
>  include/linux/lockdep.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> index 08b0d1d9d78b..df8fa5929de7 100644
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -173,7 +173,7 @@ static inline void lockdep_init_map(struct lockdep_map *lock, const char *name,
>  			      (lock)->dep_map.lock_type)
>  
>  #define lockdep_set_subclass(lock, sub)					\
> -	lockdep_init_map_type(&(lock)->dep_map, #lock, (lock)->dep_map.key, sub,\
> +	lockdep_init_map_type(&(lock)->dep_map, (lock)->dep_map.name, (lock)->dep_map.key, sub,\
>  			      (lock)->dep_map.wait_type_inner,		\
>  			      (lock)->dep_map.wait_type_outer,		\
>  			      (lock)->dep_map.lock_type)
> -- 
> 2.45.2




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux