From: David Jeffery <djeffery@redhat.com>
To: driver-core@lists.linux.dev,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linux-scsi@vger.kernel.org, Tarun Sahu <tarunsahu@google.com>,
Stuart Hayes <stuart.w.hayes@gmail.com>,
Laurence Oberman <loberman@redhat.com>,
Bjorn Helgaas <helgaas@kernel.org>,
kexec@lists.infradead.org, David Jeffery <djeffery@redhat.com>
Subject: [PATCH 5/9] driver core: do not always lock parent in shutdown
Date: Fri, 21 Aug 2026 10:24:10 -0400 [thread overview]
Message-ID: <20260821142414.150892-6-djeffery@redhat.com> (raw)
In-Reply-To: <20260821142414.150892-1-djeffery@redhat.com>
Don't lock a parent device unless it is needed in device_shutdown. This
is in preparation for making device shutdown asynchronous, when it will
be needed to allow children of a common parent to shut down
simultaneously.
And only acquire a reference to the parent device if the parent is to be
locked.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: David Jeffery <djeffery@redhat.com>
Signed-off-by: Tarun Sahu <tarunsahu@google.com>
Tested-by: Laurence Oberman <loberman@redhat.com>
---
The sashiko patch analysis may complain about the parent locking and
possible use of device_move. This issue cannot currently happen as
devices with need_parent_lock do not use device_move. An earlier patch
also adds a warning for this condition should some future code change
violate the incompatibility between need_parent_lock and device_move.
drivers/base/core.c | 44 ++++++++++++++++++++++++++++----------------
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index a94d24b30c30..cd725466c32d 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -4910,12 +4910,10 @@ int device_change_owner(struct device *dev, kuid_t kuid, kgid_t kgid)
return error;
}
-static void shutdown_one_device(struct device *dev, struct device *parent)
+static void __shutdown_one_device(struct device *dev)
{
- /* hold lock to avoid race with probe/release */
- if (parent)
- device_lock(parent);
- device_lock(dev);
+ if (!dev->p || dev->p->dead)
+ return;
/* Don't allow any more runtime suspends */
pm_runtime_get_noresume(dev);
@@ -4935,13 +4933,33 @@ static void shutdown_one_device(struct device *dev, struct device *parent)
dev_info(dev, "shutdown\n");
dev->driver->shutdown(dev);
}
+}
- device_unlock(dev);
- if (parent)
+static void shutdown_one_device(struct device *dev)
+{
+ struct device *parent;
+
+ device_lock(dev);
+
+ /* use parent lock if needed to avoid race with probe/release */
+ if (dev->bus && dev->bus->need_parent_lock && dev->p && !dev->p->dead &&
+ (parent = get_device(dev->parent))) {
+ /* the parent lock needs to be acquired first, so re-lock */
+ device_unlock(dev);
+
+ device_lock(parent);
+ device_lock(dev);
+
+ __shutdown_one_device(dev);
+ device_unlock(dev);
device_unlock(parent);
+ put_device(parent);
+ } else {
+ __shutdown_one_device(dev);
+ device_unlock(dev);
+ }
put_device(dev);
- put_device(parent);
}
/**
@@ -4949,7 +4967,7 @@ static void shutdown_one_device(struct device *dev, struct device *parent)
*/
void device_shutdown(void)
{
- struct device *dev, *parent;
+ struct device *dev;
wait_for_device_probe();
device_block_probing();
@@ -4966,12 +4984,6 @@ void device_shutdown(void)
dev = list_entry(devices_kset->list.prev, struct device,
kobj.entry);
- /*
- * hold reference count of device's parent to
- * prevent it from being freed because parent's
- * lock is to be held
- */
- parent = get_device(dev->parent);
get_device(dev);
/*
* Make sure the device is off the kset list, in the
@@ -4980,7 +4992,7 @@ void device_shutdown(void)
list_del_init(&dev->kobj.entry);
spin_unlock(&devices_kset->list_lock);
- shutdown_one_device(dev, parent);
+ shutdown_one_device(dev);
spin_lock(&devices_kset->list_lock);
}
--
2.55.0
next prev parent reply other threads:[~2026-08-21 14:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 14:24 [PATCH v20 0/9] shut down devices asynchronously David Jeffery
2026-08-21 14:24 ` [PATCH 1/9] driver core: rely on put_device to free dev->p David Jeffery
2026-08-21 14:32 ` sashiko-bot
2026-08-21 14:24 ` [PATCH 2/9] driver core: prevent device_add() during system shutdown David Jeffery
2026-08-21 14:43 ` sashiko-bot
2026-08-28 16:01 ` tarunsahu
2026-08-21 14:24 ` [PATCH 3/9] driver core: warn should device_move try to move a need_parent_lock device David Jeffery
2026-08-21 14:34 ` sashiko-bot
2026-08-28 15:50 ` tarunsahu
2026-08-21 14:24 ` [PATCH 4/9] driver core: separate function to shutdown one device David Jeffery
2026-08-21 14:29 ` sashiko-bot
2026-08-21 14:24 ` David Jeffery [this message]
2026-08-21 14:33 ` [PATCH 5/9] driver core: do not always lock parent in shutdown sashiko-bot
2026-08-21 14:24 ` [PATCH 6/9] driver core: async device shutdown infrastructure David Jeffery
2026-08-21 14:38 ` sashiko-bot
2026-08-21 14:24 ` [PATCH 7/9] PCI: Link a virtual function to its physical function David Jeffery
2026-08-21 14:34 ` sashiko-bot
2026-08-21 14:24 ` [PATCH 8/9] PCI: Enable async shutdown support David Jeffery
2026-08-21 14:39 ` sashiko-bot
2026-08-21 14:24 ` [PATCH 9/9] scsi: " David Jeffery
2026-08-21 14:38 ` sashiko-bot
-- strict thread matches above, loose matches on Subject: below --
2026-09-02 17:07 [PATCH v21 0/9] shut down devices asynchronously David Jeffery
2026-09-02 17:07 ` [PATCH 5/9] driver core: do not always lock parent in shutdown David Jeffery
2026-09-02 17:25 ` sashiko-bot
2026-09-17 16:37 [PATCH v22 0/9] shut down devices asynchronously David Jeffery
2026-09-17 16:37 ` [PATCH 5/9] driver core: do not always lock parent in shutdown David Jeffery
2026-09-17 16:46 ` sashiko-bot
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=20260821142414.150892-6-djeffery@redhat.com \
--to=djeffery@redhat.com \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=loberman@redhat.com \
--cc=rafael@kernel.org \
--cc=stuart.w.hayes@gmail.com \
--cc=tarunsahu@google.com \
/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.