Linux-i3c Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sam Agazaryan" <samagazaryan@google.com>
Cc: Frank.Li@kernel.org,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	linux-i3c@lists.infradead.org
Subject: Re: [PATCH v4 2/3] i3c: master: add i3c_for_each_dev helper
Date: Sun, 06 Sep 2026 20:40:19 +0000	[thread overview]
Message-ID: <20260906204020.2F9FD1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260906202747.4041389-3-samagazaryan@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unnecessary acquisition of `i3c_core_lock` in `i3c_for_each_dev` creates a deadlock risk and introduces a lock inversion with device release paths.
--

commit cf4ed3e7da2ded8dc5ec7a5d74c745aae27e4e0a
Author: Vitor Soares <vitor.soares@toradex.com>

i3c: master: add i3c_for_each_dev helper

Introduce i3c_for_each_dev(), an i3c device iterator for use by i3cdev.

> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index e8a9f8c3041e6..dd5071ca9195a 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
> @@ -4011,6 +4011,18 @@ void i3c_dev_free_ibi_locked(struct i3c_dev_desc *dev)
>  }
>  EXPORT_SYMBOL_GPL(i3c_dev_free_ibi_locked);
>  
> +int i3c_for_each_dev(void *data, int (*fn)(struct device *, void *))
> +{
> +	int res;
> +
> +	mutex_lock(&i3c_core_lock);
> +	res = bus_for_each_dev(&i3c_bus_type, NULL, data, fn);

[Severity: High]
Does holding i3c_core_lock here create a potential deadlock risk?

Since bus_for_each_dev() invokes an opaque callback fn() over all bus
devices, if fn() performs an action that drops the last reference to an I3C
master controller device, the release function i3c_masterdev_release() could
execute synchronously on the same thread.

If that occurs, i3c_masterdev_release() calls i3c_bus_cleanup(), which
unconditionally attempts to lock i3c_core_lock:

drivers/i3c/master.c:i3c_bus_cleanup() {
    ...
    mutex_lock(&i3c_core_lock);
    idr_remove(&i3c_bus_idr, i3cbus->id);
    mutex_unlock(&i3c_core_lock);
    ...
}

Because i3c_core_lock appears to exclusively protect the subsystem IDR
(i3c_bus_idr) rather than the driver core device list used by
bus_for_each_dev(), can we safely perform this iteration without holding
the global lock to avoid this inversion?

> +	mutex_unlock(&i3c_core_lock);
> +
> +	return res;
> +}
> +EXPORT_SYMBOL_GPL(i3c_for_each_dev);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260906202747.4041389-1-samagazaryan@google.com?part=2

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

  reply	other threads:[~2026-09-06 20:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-06 20:27 [PATCH v4 0/3] i3c: Introduce i3c device userspace interface Sam Agazaryan
2026-09-06 20:27 ` [PATCH v4 1/3] i3c: master: export i3c_masterdev_type Sam Agazaryan
2026-09-06 20:27 ` [PATCH v4 2/3] i3c: master: add i3c_for_each_dev helper Sam Agazaryan
2026-09-06 20:40   ` sashiko-bot [this message]
2026-09-06 20:27 ` [PATCH v4 3/3] i3c: add i3cdev module to expose i3c dev in /dev Sam Agazaryan
2026-09-06 20:41   ` sashiko-bot
2026-09-07 14:40   ` Greg Kroah-Hartman
2026-09-09  6:13     ` Sam Agazaryan
2026-09-09 21:51   ` Frank Li
2026-09-11  3:44     ` Sam Agazaryan
2026-09-11 15:10       ` Frank Li
2026-09-11 23:57         ` Sam Agazaryan
2026-09-11 19:03       ` Adrian Hunter
2026-09-11 22:05   ` Meagan Lloyd
2026-09-12  0:12     ` Sam Agazaryan
2026-09-08 11:48 ` [PATCH v4 0/3] i3c: Introduce i3c device userspace interface Wolfram Sang
2026-09-12 11:12 ` Wolfram Sang

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=20260906204020.2F9FD1F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=linux-i3c@lists.infradead.org \
    --cc=samagazaryan@google.com \
    --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