Re: [PATCH v5] driver core: enforce device_lock for driver_match_device()

["Danilo Krummrich" <dakr@kernel.org>]

On Tue Jan 20, 2026 at 6:38 PM CET, Mark Brown wrote:
> On Tue, Jan 20, 2026 at 04:03:03PM +0100, Danilo Krummrich wrote:
>
>> I don't have a machine to reproduce it, but for debugging it would probably help
>> to not actually take the lock in __driver_attach(), but only acquire / release
>> the corresponding lockdep map. If my suspicion is correct, we should see a
>> lockdep splat pointing out the issue.
>
> 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).

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)