From: sashiko-bot@kernel.org
To: "Adrian Hunter" <adrian.hunter@intel.com>
Cc: linux-i3c@lists.infradead.org, linux-pci@vger.kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
Frank.Li@kernel.org
Subject: Re: [PATCH RFC RESEND 3/7] i3c: master: Add helper to query bus wakeup requirements
Date: Wed, 01 Jul 2026 20:33:14 +0000 [thread overview]
Message-ID: <20260701203315.6114A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701201533.220818-4-adrian.hunter@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Concurrent execution between `i3c_master_any_wakeup_enabled()` and the device registration worker causes data races on `desc->dev` because both paths use a read-side lock.
Pre-existing issues:
- [High] The `i3c_master_any_wakeup_enabled()` helper can dereference a dangling `desc->dev` pointer if a previous I3C device registration failed.
--
commit 3ed97d097ea9f23fefcb772811737adab713eb66
Author: Adrian Hunter <adrian.hunter@intel.com>
i3c: master: Add helper to query bus wakeup requirements
This commit adds i3c_master_any_wakeup_enabled(), which iterates over the
devices on an I3C bus and reports whether any of them are enabled for system
wakeup. Controller drivers can use this helper to determine whether wakeup
support must remain available while the system is suspended.
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index a36f9b617cbf7..979457e635bd9 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
[ ... ]
> +bool i3c_master_any_wakeup_enabled(struct i3c_master_controller *master)
> +{
> + struct i3c_dev_desc *desc;
> + bool wakeup = false;
> +
> + i3c_bus_normaluse_lock(&master->bus);
[Severity: High]
Does this code risk a data race with the device registration worker?
Looking at i3c_master_reg_work_fn(), it allocates and initializes desc->dev
while holding this same read-side lock (i3c_bus_normaluse_lock). If the PCI
controller runtime suspends and calls this helper while the registration work
is executing, they can run concurrently since both only hold a read-side
lock.
Can this lead to a use-before-initialization if device_may_wakeup() is
called while the memory is still being initialized?
> + i3c_bus_for_each_i3cdev(&master->bus, desc) {
> + if (desc->dev && device_may_wakeup(&desc->dev->dev)) {
[Severity: High]
This is a pre-existing issue, but could this check trigger a use-after-free
if a previous device registration failed?
In i3c_master_register_new_i3c_devs(), if device_register() fails, the error
path drops the reference with put_device(&desc->dev->dev). This frees the
underlying memory, but desc->dev is never set to NULL.
If that happens, won't this loop observe a dangling non-NULL desc->dev
pointer and unconditionally dereference it during suspend?
> + wakeup = true;
> + break;
> + }
> + }
> + i3c_bus_normaluse_unlock(&master->bus);
> +
> + return wakeup;
> +}
> +EXPORT_SYMBOL_GPL(i3c_master_any_wakeup_enabled);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701201533.220818-1-adrian.hunter@intel.com?part=3
next prev parent reply other threads:[~2026-07-01 20:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 20:15 [PATCH RFC RESEND 0/7] i3c: Support IBI-based system wakeup Adrian Hunter
2026-07-01 20:15 ` [PATCH RFC RESEND 1/7] i3c: master: Support IBI-based wakeup capability Adrian Hunter
2026-07-01 20:30 ` sashiko-bot
2026-07-02 14:10 ` Frank Li
2026-07-01 20:15 ` [PATCH RFC RESEND 2/7] i3c: master: Report wakeup events for IBIs Adrian Hunter
2026-07-01 20:33 ` sashiko-bot
2026-07-02 10:38 ` Adrian Hunter
2026-07-01 20:15 ` [PATCH RFC RESEND 3/7] i3c: master: Add helper to query bus wakeup requirements Adrian Hunter
2026-07-01 20:33 ` sashiko-bot [this message]
2026-07-01 20:15 ` [PATCH RFC RESEND 4/7] i3c: master: Reject IBI requests from non-IBI-capable devices Adrian Hunter
2026-07-01 20:29 ` sashiko-bot
2026-07-01 20:15 ` [PATCH RFC RESEND 5/7] i3c: mipi-i3c-hci-pci: Propagate I3C wakeup requirements to PCI Adrian Hunter
2026-07-01 20:33 ` sashiko-bot
2026-07-01 20:15 ` [PATCH RFC RESEND 6/7] i3c: mipi-i3c-hci: Factor out i3c_hci_sysdev() Adrian Hunter
2026-07-01 20:23 ` sashiko-bot
2026-07-01 20:15 ` [PATCH RFC RESEND 7/7] i3c: mipi-i3c-hci: Advertise IBI wakeup capability Adrian Hunter
2026-07-01 20:22 ` 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=20260701203315.6114A1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox