All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Trevor Chan" <trev@trevrosa.dev>
Cc: ojeda@kernel.org, linux-pci@vger.kernel.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v7] rust: aref: make `AlwaysRefCounted::inc_ref` an associated function
Date: Sun, 28 Jun 2026 10:14:07 +0000	[thread overview]
Message-ID: <20260628101407.D29EC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260628100731.64885-1-trev@trevrosa.dev>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] `I2cAdapter::inc_ref` calls `i2c_get_adapter()` which sleeps and can fail, leading to sleep-in-atomic panics and Use-After-Free.
--

commit dcdb7e5879ef4f6a18646d7f509abd59ae6f10db
Author: Trevor Chan <trev@trevrosa.dev>

rust: aref: make AlwaysRefCounted::inc_ref an associated function

This commit changes the AlwaysRefCounted::inc_ref trait method to be an
associated function rather than taking a self reference. This prevents
accidental calls to inc_ref on types that implement it, and updates all
implementors across various kernel subsystems to match the new signature.

Link: https://github.com/Rust-for-Linux/linux/issues/1177

[ ... ]

> diff --git a/rust/kernel/i2c.rs b/rust/kernel/i2c.rs
> index 624b971ca8b0b..1a9882a64c4b8 100644
> --- a/rust/kernel/i2c.rs
> +++ b/rust/kernel/i2c.rs
> @@ -425,9 +425,9 @@ pub fn get(index: i32) -> Result<ARef<Self>> {
>  
>  // SAFETY: Instances of `I2cAdapter` are always reference-counted.
>  unsafe impl AlwaysRefCounted for I2cAdapter {
> -    fn inc_ref(&self) {
> +    fn inc_ref(obj: &Self) {
>          // SAFETY: The existence of a shared reference guarantees that the refcount is non-zero.
> -        unsafe { bindings::i2c_get_adapter(self.index()) };
> +        unsafe { bindings::i2c_get_adapter(obj.index()) };

[Severity: High]
This isn't a bug introduced by this patch, but is it safe for
I2cAdapter::inc_ref to call i2c_get_adapter here?

Since i2c_get_adapter acquires a mutex (core_lock), won't cloning an
ARef<I2cAdapter> in an atomic context (such as under a spinlock) trigger
a sleep-in-atomic panic?

Additionally, does this code handle the case where i2c_get_adapter fails?
If the adapter has been unregistered (e.g., the device is hot-unplugged or
the driver unbound) while the ARef is still held, the IDR lookup fails and
i2c_get_adapter returns NULL.

Because this return value is ignored in inc_ref, the underlying device
and module refcounts wouldn't actually be incremented. When the cloned ARef
is subsequently dropped, dec_ref will unconditionally decrement the
refcounts, which could underflow and cause a use-after-free while other
ARef instances still point to it.

>      }
>  
>      unsafe fn dec_ref(obj: NonNull<Self>) {

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260628100731.64885-1-trev@trevrosa.dev?part=1

      reply	other threads:[~2026-06-28 10:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-28 10:07 [PATCH v7] rust: aref: make `AlwaysRefCounted::inc_ref` an associated function Trevor Chan
2026-06-28 10:14 ` sashiko-bot [this message]

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=20260628101407.D29EC1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=trev@trevrosa.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 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.