linux-kernel - Re: [PATCH v5] driver core: enforce device_lock for driver_match

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <DFTQA8QQGD2G.10F1VGDBY86LL@kernel.org>
Date: Tue, 20 Jan 2026 22:18:36 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Mark Brown" <broonie@...nel.org>
Cc: "Gui-Dong Han" <hanguidong02@...il.com>, <gregkh@...uxfoundation.org>,
 <rafael@...nel.org>, <linux-kernel@...r.kernel.org>,
 <baijiaju1990@...il.com>, "Qiu-ji Chen" <chenqiuji666@...il.com>,
 <Aishwarya.TCV@....com>, "Marek Szyprowski" <m.szyprowski@...sung.com>
Subject: Re: [PATCH v5] driver core: enforce device_lock for
 driver_match_device()

On Tue Jan 20, 2026 at 9:05 PM CET, Mark Brown wrote:
> On Tue, Jan 20, 2026 at 07:36:05PM +0100, Danilo Krummrich wrote:
>> On Tue Jan 20, 2026 at 6:38 PM CET, Mark Brown wrote:
>
>> > I tried lockdep but didn't see anything different.  Instrumenting with
>> > printk() tells me it's deadlocking trying to attach arm-smmu on Juno
>> > (that's a v1 SMMU on this platform), I'll try to poke further but it'll
>> > likely be tomorrow at the earliest.
>
>> Maybe the following diff faking the lock for lockdep helps, as it should keep
>> things running, i.e. with this we have the exact same semantics as if we'd
>> revert the patch (except for the lockdep check of course).
>
> That does allow us to continue to make progress, the SMMU never manages
> to probe AFAICT but we do boot normally.

I really would expect a lockdep splat in this case, so I was even about to ask
whether CONFIG_PROVE_LOCKING etc. is enabled. But it's me who messed it up. I
missed that we have lockdep_set_novalidate_class(&dev->mutex).

(The fact that the SMMU never manages to probe must be unrelated, i.e. a
different issue. Since my diff should be equivalent to a revert of the patch,
except that it fakes that the mutex has been taken for lockdep.)

Anyways, this should work:

diff --git a/drivers/base/base.h b/drivers/base/base.h
index 677320881af1..4741412d7e46 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -190,8 +190,13 @@ static inline int driver_match_device(const struct device_driver *drv,
 static inline int driver_match_device_locked(const struct device_driver *drv,
                                             struct device *dev)
 {
-       guard(device)(dev);
-       return driver_match_device(drv, dev);
+       int ret;
+
+       mutex_acquire(&dev->mutex.dep_map, 0, 0, _THIS_IP_);
+       ret = driver_match_device(drv, dev);
+       mutex_release(&dev->mutex.dep_map, _THIS_IP_);
+
+       return ret;
 }

 static inline void dev_sync_state(struct device *dev)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 40de2f51a1b1..af270362aeb7 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3159,7 +3159,7 @@ void device_initialize(struct device *dev)
        kobject_init(&dev->kobj, &device_ktype);
        INIT_LIST_HEAD(&dev->dma_pools);
        mutex_init(&dev->mutex);
-       lockdep_set_novalidate_class(&dev->mutex);
+       //lockdep_set_novalidate_class(&dev->mutex);
        spin_lock_init(&dev->devres_lock);
        INIT_LIST_HEAD(&dev->devres_head);
        device_pm_init(dev);