linux-stable.git/drivers/base/dd.c, branch v6.12.91

driver core: Don't let a device probe until it's ready

2026-05-07T04:09:24+00:00

commit a2225b6e834a838ae3c93709760edc0a169eb2f2 upstream.

The moment we link a "struct device" into the list of devices for the
bus, it's possible probe can happen. This is because another thread
can load the driver at any time and that can cause the device to
probe. This has been seen in practice with a stack crawl that looks
like this [1]:

  really_probe()
  __driver_probe_device()
  driver_probe_device()
  __driver_attach()
  bus_for_each_dev()
  driver_attach()
  bus_add_driver()
  driver_register()
  __platform_driver_register()
  init_module() [some module]
  do_one_initcall()
  do_init_module()
  load_module()
  __arm64_sys_finit_module()
  invoke_syscall()

As a result of the above, it was seen that device_links_driver_bound()
could be called for the device before "dev->fwnode->dev" was
assigned. This prevented __fw_devlink_pickup_dangling_consumers() from
being called which meant that other devices waiting on our driver's
sub-nodes were stuck deferring forever.

It's believed that this problem is showing up suddenly for two
reasons:
1. Android has recently (last ~1 year) implemented an optimization to
   the order it loads modules [2]. When devices opt-in to this faster
   loading, modules are loaded one-after-the-other very quickly. This
   is unlike how other distributions do it. The reproduction of this
   problem has only been seen on devices that opt-in to Android's
   "parallel module loading".
2. Android devices typically opt-in to fw_devlink, and the most
   noticeable issue is the NULL "dev->fwnode->dev" in
   device_links_driver_bound(). fw_devlink is somewhat new code and
   also not in use by all Linux devices.

Even though the specific symptom where "dev->fwnode->dev" wasn't
assigned could be fixed by moving that assignment higher in
device_add(), other parts of device_add() (like the call to
device_pm_add()) are also important to run before probe. Only moving
the "dev->fwnode->dev" assignment would likely fix the current
symptoms but lead to difficult-to-debug problems in the future.

Fix the problem by preventing probe until device_add() has run far
enough that the device is ready to probe. If somehow we end up trying
to probe before we're allowed, __driver_probe_device() will return
-EPROBE_DEFER which will make certain the device is noticed.

In the race condition that was seen with Android's faster module
loading, we will temporarily add the device to the deferred list and
then take it off immediately when device_add() probes the device.

Instead of adding another flag to the bitfields already in "struct
device", instead add a new "flags" field and use that. This allows us
to freely change the bit from different thread without worrying about
corrupting nearby bits (and means threads changing other bit won't
corrupt us).

[1] Captured on a machine running a downstream 6.6 kernel
[2] https://cs.android.com/android/platform/superproject/main/+/main:system/core/libmodprobe/libmodprobe.cpp?q=LoadModulesParallel

Cc: stable@vger.kernel.org
Fixes: 2023c610dc54 ("Driver core: add new device to bus's list before probing")
Reviewed-by: Alan Stern 
Reviewed-by: Rafael J. Wysocki (Intel) 
Reviewed-by: Danilo Krummrich 
Acked-by: Greg Kroah-Hartman 
Acked-by: Marek Szyprowski 
Signed-off-by: Douglas Anderson 
Link: https://patch.msgid.link/20260406162231.v5.1.Id750b0fbcc94f23ed04b7aecabcead688d0d8c17@changeid
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

driver core: generalize driver_override in struct device

2026-04-02T11:09:25+00:00

[ Upstream commit cb3d1049f4ea77d5ad93f17d8ac1f2ed4da70501 ]

Currently, there are 12 busses (including platform and PCI) that
duplicate the driver_override logic for their individual devices.

All of them seem to be prone to the bug described in [1].

While this could be solved for every bus individually using a separate
lock, solving this in the driver-core generically results in less (and
cleaner) changes overall.

Thus, move driver_override to struct device, provide corresponding
accessors for busses and handle locking with a separate lock internally.

In particular, add device_set_driver_override(),
device_has_driver_override(), device_match_driver_override() and
generalize the sysfs store() and show() callbacks via a driver_override
feature flag in struct bus_type.

Until all busses have migrated, keep driver_set_override() in place.

Note that we can't use the device lock for the reasons described in [2].

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220789 [1]
Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [2]
Tested-by: Gui-Dong Han 
Co-developed-by: Gui-Dong Han 
Signed-off-by: Gui-Dong Han 
Reviewed-by: Greg Kroah-Hartman 
Link: https://patch.msgid.link/20260303115720.48783-2-dakr@kernel.org
[ Use dev->bus instead of sp->bus for consistency; fix commit message to
  refer to the struct bus_type's driver_override feature flag. - Danilo ]
Signed-off-by: Danilo Krummrich 
Stable-dep-of: 2b38efc05bf7 ("driver core: platform: use generic driver_override infrastructure")
Signed-off-by: Sasha Levin

Revert "driver core: enforce device_lock for driver_match_device()"

2026-02-16T16:09:13+00:00

This reverts commit cd0e0a76e40c2e77bcfc88291d00dca22b00158e which is
commit dc23806a7c47ec5f1293aba407fb69519f976ee0 upstream.

It causes boot regressions on some systems as all of the "fixes" for
drivers are not properly backported yet.  Once that is completed, only
then can this be applied, if really necessary given the potential for
explosions, perhaps we might want to wait a few -rc releases first...

Cc: Danilo Krummrich 
Cc: Rafael J. Wysocki (Intel) 
Cc: Danilo Krummrich 
Cc: Gui-Dong Han 
Cc: Qiu-ji Chen 
Reported-by: Mark Brown 
Link: https://lore.kernel.org/r/7dfd0e63-a725-4fac-b2a0-f2e621d99d1b@sirena.org.uk
Signed-off-by: Greg Kroah-Hartman

driver core: enforce device_lock for driver_match_device()

2026-02-16T09:18:43+00:00

commit dc23806a7c47ec5f1293aba407fb69519f976ee0 upstream.

Currently, driver_match_device() is called from three sites. One site
(__device_attach_driver) holds device_lock(dev), but the other two
(bind_store and __driver_attach) do not. This inconsistency means that
bus match() callbacks are not guaranteed to be called with the lock
held.

Fix this by introducing driver_match_device_locked(), which guarantees
holding the device lock using a scoped guard. Replace the unlocked calls
in bind_store() and __driver_attach() with this new helper. Also add a
lock assertion to driver_match_device() to enforce this guarantee.

This consistency also fixes a known race condition. The driver_override
implementation relies on the device_lock, so the missing lock led to the
use-after-free (UAF) reported in Bugzilla for buses using this field.

Stress testing the two newly locked paths for 24 hours with
CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled showed no UAF recurrence
and no lockdep warnings.

Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
Suggested-by: Qiu-ji Chen 
Signed-off-by: Gui-Dong Han 
Fixes: 49b420a13ff9 ("driver core: check bus->match without holding device lock")
Reviewed-by: Danilo Krummrich 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Rafael J. Wysocki (Intel) 
Link: https://patch.msgid.link/20260113162843.12712-1-hanguidong02@gmail.com
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

driver core: introduce device_set_driver() helper

2025-05-02T05:59:28+00:00

commit 04d3e5461c1f5cf8eec964ab64948ebed826e95e upstream.

In preparation to closing a race when reading driver pointer in
dev_uevent() code, instead of setting device->driver pointer directly
introduce device_set_driver() helper.

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Masami Hiramatsu (Google) 
Link: https://lore.kernel.org/r/20250311052417.1846985-2-dmitry.torokhov@gmail.com
Signed-off-by: Greg Kroah-Hartman

Merge tag 'driver-core-6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2024-09-27T15:48:37+00:00

Pull driver core updates from Greg KH:
 "Here is a small set of patches for the driver core code for 6.12-rc1.

  This set is the one that caused the most delay on my side, due to lots
  of last-minute reports of problems in the async shutdown feature that
  was added. In the end, I've reverted all of the patches in that series
  so we are back to "normal" and the patch set is being reworked for the
  next merge window.

  Other than the async shutdown patches that were reverted, included in
  here are:

   - minor driver core cleanups

   - minor driver core bus and class api cleanups and simplifications
     for some callbacks

   - some const markings of structures

   - other even more minor cleanups

  All of these, including the last minute reverts, have been in
  linux-next, but all of the reports of problems in linux-next were
  before the reverts happened. After the reverts, all is good"

* tag 'driver-core-6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (32 commits)
  Revert "driver core: don't always lock parent in shutdown"
  Revert "driver core: separate function to shutdown one device"
  Revert "driver core: shut down devices asynchronously"
  Revert "nvme-pci: Make driver prefer asynchronous shutdown"
  Revert "driver core: fix async device shutdown hang"
  driver core: fix async device shutdown hang
  driver core: attribute_container: Remove unused functions
  driver core: Trivially simplify ((struct device_private *)curr)->device->p to @curr
  devres: Correclty strip percpu address space of devm_free_percpu() argument
  driver core: Make parameter check consistent for API cluster device_(for_each|find)_child()
  bus: fsl-mc: make fsl_mc_bus_type const
  nvme-pci: Make driver prefer asynchronous shutdown
  driver core: shut down devices asynchronously
  driver core: separate function to shutdown one device
  driver core: don't always lock parent in shutdown
  platform: Make platform_bus_type constant
  driver core: class: Check namespace relevant parameters in class_register()
  driver:base:core: Adding a "Return:" line in comment for device_link_add()
  drivers/base: Introduce device_match_t for device finding APIs
  firmware_loader: Block path traversal
  ...

driver core: Trivially simplify ((struct device_private *)curr)->device->p to @curr

2024-09-11T14:31:02+00:00

Trivially simplify ((struct device_private *)curr)->device->p to @curr
in deferred_devs_show() since both are same.

Signed-off-by: Zijun Hu 
Link: https://lore.kernel.org/r/20240908-trivial_simpli-v1-1-53e0f1363299@quicinc.com
Signed-off-by: Greg Kroah-Hartman

platform: Add test managed platform_device/driver APIs

2024-07-29T22:33:12+00:00

Introduce KUnit resource wrappers around platform_driver_register(),
platform_device_alloc(), and platform_device_add() so that test authors
can register platform drivers/devices from their tests and have the
drivers/devices automatically be unregistered when the test is done.

This makes test setup code simpler when a platform driver or platform
device is needed. Add a few test cases at the same time to make sure the
APIs work as intended.

Cc: Brendan Higgins 
Reviewed-by: David Gow 
Cc: Rae Moar 
Reviewed-by: Greg Kroah-Hartman 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20240718210513.3801024-6-sboyd@kernel.org

driver core: make [device_]driver_attach take a const *

2024-06-20T10:51:42+00:00

Change device_driver_attach() and driver_attach() to take a const * to
struct device driver as neither of them modify the structure at all.

Also, for some odd reason, drivers/dma/idxd/compat.c had a duplicate
external reference to device_driver_attach(), so remove that to fix up
the build, it should never have had that there in the first place.

Cc: Rafael J. Wysocki 
Cc: Fenghua Yu 
Cc: Dave Jiang 
Cc: Vinod Koul 
Cc: Andy Shevchenko 
Cc: Petr Tesarik 
Cc: Alexander Lobakin 
Cc: dmaengine@vger.kernel.org
Link: https://lore.kernel.org/r/2024061401-rasping-manger-c385@gregkh
Signed-off-by: Greg Kroah-Hartman

driver core: mark async_driver as a const *

2024-06-13T14:44:00+00:00

Within struct device_private, mark the async_driver * as const as it is
never modified.  This requires some internal-to-the-driver-core
functions to also have their parameters marked as constant, and there is
one place where we cast _back_ from the const pointer to a real one, as
the driver core still wants to modify the structure in a number of
remaining places.

Cc: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/20240611130103.3262749-12-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman