Re: [PATCH] locking/lockdep: fix null-ptr-deref in check_prev_add()

[Peter Zijlstra]

On Fri, Nov 18, 2022 at 04:31:02PM +0800, Yang Yingliang wrote:
> I got a null-ptr-deref report as following:
> 
> general protection fault, probably for non-canonical address 0xdffffc0000000008: 0000 [#1] PREEMPT SMP KASAN PTI
> KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047]
> CPU: 0 PID: 500 Comm: systemd-udevd Tainted: G        W          6.1.0-rc5-00144-gabd8ea84ca72-dirty #1320
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
> RIP: 0010:check_prevs_add+0x2f8/0x2780
> Call Trace:
>  <TASK>
>  __lock_acquire+0x2ae8/0x3d60
>  lock_acquire+0x195/0x4e0
>  fs_reclaim_acquire+0x119/0x160
>  kmem_cache_alloc_node+0x47/0x310
>  __alloc_skb+0x205/0x2d0
>  devlink_compat_running_version+0x10b/0x6a0
>  dev_ethtool+0x285/0x380
>  dev_ioctl+0x16c/0xff0
>  sock_do_ioctl+0x1ae/0x220
>  sock_ioctl+0x55f/0x600
>  __x64_sys_ioctl+0x156/0x1d0
>  do_syscall_64+0x37/0x90
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> 
> If in use bit of lock_class is not set, hlock_class() returns NULL,

Why is that a valid premise?

That is; you think it is OK for a held_lock to not have an in-use
lock_class?

I'm thinking there's more to this problem you found.