From: sashiko-bot@kernel.org
To: "Tarun Sahu" <tarunsahu@google.com>
Cc: linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH v19 3/7] driver core: separate function to shutdown one device
Date: Fri, 17 Jul 2026 02:49:37 +0000 [thread overview]
Message-ID: <20260717024938.128D91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260716230411.2767394-4-tarunsahu@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The refactored `device_shutdown` discards the parent device pointer returned by `get_device(dev->parent)` and re-reads `dev->parent` inside `shutdown_one_device()`, creating a TOCTOU race condition that can lead to reference leaks and use-after-free.
--
--- Patch [3]: [PATCH v19 3/7] driver core: separate function to shutdown one device ---
commit c3cdb15ac9b6efba6077cade25c652c124eaa9c7
Author: David Jeffery <djeffery@redhat.com>
driver core: separate function to shutdown one device
This commit refactors device_shutdown() by extracting the shutdown logic for a
single device into a new separate function, shutdown_one_device(). This change
is intended as a preparatory step for supporting asynchronous device shutdown.
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 78b90326addb6..82a7af1f3ba2e 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -4898,12 +4898,48 @@ 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 = dev->parent;
[Severity: High]
Does this lockless read of dev->parent introduce a race condition?
In the old code, the parent device pointer was captured and pinned in
device_shutdown() using parent = get_device(dev->parent).
With this refactoring, dev->parent is re-read here. If the parent changes
concurrently (for example, via device_move()), could we end up operating on a
parent device that we do not hold a reference to?
> +
> + /* hold lock to avoid race with probe/release */
> + if (parent)
> + device_lock(parent);
[ ... ]
> @@ -4925,7 +4961,7 @@ void device_shutdown(void)
> * prevent it from being freed because parent's
> * lock is to be held
> */
> - parent = get_device(dev->parent);
> + get_device(dev->parent);
[Severity: High]
Is there a reference leak here since the return value of get_device() is now
discarded?
If dev->parent changes right after this call, the original parent's reference
will be leaked. Later, shutdown_one_device() will lock and drop a reference
to the new parent instead, potentially leading to unbalanced reference counts
and use-after-free.
Should we pass the pinned parent device pointer into shutdown_one_device()
as an argument to ensure we lock and release the exact same device we took a
reference to?
> get_device(dev);
> /*
> * Make sure the device is off the kset list, in the
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716230411.2767394-1-tarunsahu@google.com?part=3
next prev parent reply other threads:[~2026-07-17 2:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 23:04 [PATCH v19 0/7] shut down devices asynchronously Tarun Sahu
2026-07-16 23:04 ` [PATCH v19 1/7] device_core: rely on put_device to free dev->p Tarun Sahu
2026-07-17 3:04 ` sashiko-bot
2026-07-16 23:04 ` [PATCH v19 2/7] driver core: Prevent device_add() during system shutdown Tarun Sahu
2026-07-17 3:15 ` sashiko-bot
2026-07-16 23:04 ` [PATCH v19 3/7] driver core: separate function to shutdown one device Tarun Sahu
2026-07-17 2:49 ` sashiko-bot [this message]
2026-07-16 23:04 ` [PATCH v19 4/7] driver core: do not always lock parent in shutdown Tarun Sahu
2026-07-17 2:59 ` sashiko-bot
2026-07-16 23:04 ` [PATCH v19 5/7] driver core: async device shutdown infrastructure Tarun Sahu
2026-07-17 2:51 ` sashiko-bot
2026-07-16 23:04 ` [PATCH v19 6/7] PCI: Enable async shutdown support Tarun Sahu
2026-07-17 2:56 ` sashiko-bot
2026-07-16 23:04 ` [PATCH v19 7/7] scsi: " Tarun Sahu
2026-07-17 3:00 ` 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=20260717024938.128D91F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--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.