From: Daniel Golle <daniel@makrotopia.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Marcel Holtmann <marcel@holtmann.org>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
Miri Korenblit <miriam.rachel.korenblit@intel.com>,
driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-bluetooth@vger.kernel.org, linux-wireless@vger.kernel.org
Cc: Hans de Goede <johannes.goede@oss.qualcomm.com>
Subject: [PATCH v2 0/4] device_schedule_reprobe(): core helper and conversions
Date: Thu, 20 Aug 2026 01:32:04 +0100 [thread overview]
Message-ID: <cover.1787185594.git.daniel@makrotopia.org> (raw)
Three in-tree drivers (iwlwifi, hci_h5, btintel_pcie) schedule a
deferred re-probe of their own device from a work item whose work
function lives in module text. The hand-rolled copies share two bug
classes: the work function ends with module_put(THIS_MODULE), racing a
concurrent rmmod freeing the module text (the race
module_put_and_kthread_exit() exists to close for kthreads), and
nothing synchronizes the deferred detach against device_shutdown() or
an administrative unbind.
Patch 1 moves the deferred work into the driver core.
device_schedule_reprobe() runs builtin code, so no module reference is
needed; it checks under a single __device_driver_lock() hold that the
device is still bound to the driver that scheduled the re-probe, and
skips the detach once device_shutdown() has reached the device (a new
one-bit shutdown_done flag in struct device_private). It pins both the
device and its parent for the lifetime of the work and re-locks the
parent across the attach on buses that require it. Patches 2 and 3 are
mechanical conversions. Patch 4 (btintel_pcie) also retires that
driver's remove()-from-own-work contract, replacing the current_work()
dance with the deferred re-probe; it changes more and can be dropped
without affecting patches 1-3.
As Hans put it on the RFC: the tree already has device_reprobe() with
15 callers, so this just adds a way to run one from a worker safely
rather than having each of the open-coded copies reimplement the
locking.
This was first floated as an RFC [1]. In parallel the helper rode
along in the mxl862xx DSA firmware-update series as its patch 3, and
the v11 [2] and v12 [3] postings put it through further review: an
automated review of v12 caught a parent use-after-free (the work locks
the parent, but only the child was pinned) and a missing parent lock
across device_attach() on need_parent_lock buses. Both are fixed here.
net-next is closed and the mxl862xx feature waits for the next window,
so the helper is submitted on its own now; mxl862xx converts to it
once it lands.
Testing: Patches 1-3 were runtime-tested (backported to 7.0.11) on
Intel AX101 hardware with PROVE_LOCKING and DEBUG_OBJECTS_WORK,
driving iwlwifi's crash escalation into the re-probe path: normal
detach+rebind, an unbind racing a pending re-probe (the unbind is not
undone), rmmod with a re-probe pending (now succeeds instead of
EBUSY), and reboot with a re-probe pending; no lockdep or debugobjects
reports. The same helper was exercised by the mxl862xx v11/v12
hardware testing across repeated devlink firmware-flash and re-probe
cycles, including a re-probe pending across unbind, rmmod and reboot.
hci_h5 and btintel_pcie are compile-tested only.
Changes since the RFC (v1) [1]:
- rebased from net-next onto v7.2-rc7
- pin the parent device across the deferred work and re-lock it
across device_attach() on need_parent_lock buses (found by the
automated review of the mxl862xx v12 posting)
- schedule the work on system_dfl_wq instead of the deprecated
system_unbound_wq
- thread the series properly (the RFC's patches were unthreaded)
- drop RFC status
[1] https://lore.kernel.org/all/anpxFdwNxk0XwPjQ@makrotopia.org/
[2] https://lore.kernel.org/all/cover.1786773971.git.daniel@makrotopia.org/
[3] https://lore.kernel.org/all/cover.1786922210.git.daniel@makrotopia.org/
Daniel Golle (4):
driver core: add device_schedule_reprobe()
wifi: iwlwifi: use device_schedule_reprobe()
Bluetooth: hci_h5: use device_schedule_reprobe()
Bluetooth: btintel_pcie: use device_schedule_reprobe() after reset
drivers/base/base.h | 5 +
drivers/base/core.c | 3 +
drivers/base/dd.c | 99 +++++++++++++++++++
drivers/bluetooth/btintel_pcie.c | 51 +++++-----
drivers/bluetooth/hci_h5.c | 43 ++------
.../net/wireless/intel/iwlwifi/iwl-trans.c | 40 +-------
include/linux/device.h | 2 +
7 files changed, 144 insertions(+), 99 deletions(-)
base-commit: db2ddb87143519e20a95aa36c60b36107b736a58
--
2.55.0
next reply other threads:[~2026-08-20 0:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 0:32 Daniel Golle [this message]
2026-08-20 0:32 ` [PATCH v2 1/4] driver core: add device_schedule_reprobe() Daniel Golle
2026-08-20 2:01 ` device_schedule_reprobe(): core helper and conversions bluez.test.bot
2026-08-20 0:32 ` [PATCH v2 2/4] wifi: iwlwifi: use device_schedule_reprobe() Daniel Golle
2026-08-20 0:32 ` [PATCH v2 3/4] Bluetooth: hci_h5: " Daniel Golle
2026-08-20 0:33 ` [PATCH v2 4/4] Bluetooth: btintel_pcie: use device_schedule_reprobe() after reset Daniel Golle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1787185594.git.daniel@makrotopia.org \
--to=daniel@makrotopia.org \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=johannes.goede@oss.qualcomm.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=miriam.rachel.korenblit@intel.com \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.