Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Lorenzo Stoakes" <ljs@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Will Deacon" <will@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>,
	"Lyude Paul" <lyude@redhat.com>
Cc: linux-mm@kvack.org
Subject: Re: [PATCH v5 1/4] rust: io: require freedom from plain accesses for `SysMem`
Date: Wed, 11 Nov 2026 14:46:30 +0000	[thread overview]
Message-ID: <sashiko-outbox-209186@kernel.org> (raw)
In-Reply-To: <20261110-page-volatile-io-v5-1-a91ef252c24b@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] rust: io: SysMem::new() no-plain-access invariant violated by
  callers
--

commit 2301a5fd31bd2665dfd4001d0e9beab25a81725b
Author: Andreas Hindborg <a.hindborg@kernel.org>

rust: io: require freedom from plain accesses for `SysMem`

This commit adds a type invariant to SysMem and a safety requirement on
SysMem::new() requiring that no plain accesses are performed to the memory
region for the lifetime of the view.

> diff --git a/rust/kernel/io.rs b/rust/kernel/io.rs
> index a877df11a03e0..3bc4be35e3554 100644
> --- a/rust/kernel/io.rs
> +++ b/rust/kernel/io.rs
[ ... ]
> @@ -1570,8 +1582,10 @@ impl<'a, T: ?Sized> SysMem<'a, T> {
>      ///
>      /// # Safety
>      ///
> -    /// `ptr.addr() .. ptr.addr() + KnownSize::size(ptr)` must be valid and aligned kernel
> -    /// accessible memory region for the lifetime `'a`.
> +    /// - `ptr.addr() .. ptr.addr() + KnownSize::size(ptr)` must be valid and aligned kernel
> +    ///   accessible memory region for the lifetime `'a`.
> +    /// - No plain access (see [`SysMem`]) to that memory region may be performed for the lifetime
> +    ///   `'a`.
>      #[inline]
>      pub unsafe fn new(ptr: *mut T) -> Self {
>          // INVARIANT: Per safety requirement.

[Severity: Medium]
Does this new SysMem<'a, T> invariant conflict with the existing
SysMem::new() callers in Coherent and VMap?

In rust/kernel/dma.rs, <&'a Coherent<'_, T> as IoBase<'a>>::as_view() is a
safe method that wraps the buffer in SysMem<'a, T> inside CoherentView<'a, T>,
while CoherentView::as_ref() and CoherentView::as_mut() hand out &'a T and
&'a mut T references for plain accesses over the same lifetime 'a:

rust/kernel/dma.rs:CoherentView::as_ref() {
    pub unsafe fn as_ref(self) -> &'a T {
        // SAFETY: pointer is aligned and valid per type invariant. Aliasing rule is satisfied per
        // safety requirement.
        unsafe { &*self.cpu_addr.as_ptr() }
    }
}

rust/kernel/dma.rs:<&'a Coherent<'_, T> as IoBase<'a>>::as_view() {
    fn as_view(self) -> CoherentView<'a, Self::Target> {
        CoherentView {
            // SAFETY: `cpu_addr` is valid and aligned kernel accessible memory.
            cpu_addr: unsafe { SysMem::new(self.cpu_addr.as_ptr()) },
            dma_addr: self.dma_addr,
        }
    }
}

Any plain read or write through those references during 'a violates the
SysMem<'a, T> invariant even when no concurrent access occurs.  Similarly,
<&'a VMap<D, R, SIZE> as IoBase<'a>>::as_view() in
rust/kernel/drm/gem/shmem.rs calls SysMem::new() without VMap's invariants or
its SAFETY comment guaranteeing that no plain accesses occur during 'a.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110-page-volatile-io-v5-0-a91ef252c24b@kernel.org?part=1


  reply	other threads:[~2026-11-11 14:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 14:44 [PATCH v5 0/4] rust: byte-wise atomic copies between `Page` and shared memory Andreas Hindborg
2026-11-10 14:44 ` [PATCH v5 1/4] rust: io: require freedom from plain accesses for `SysMem` Andreas Hindborg
2026-11-11 14:46   ` sashiko-bot [this message]
2026-11-11 19:40     ` Andreas Hindborg
2026-11-10 14:44 ` [PATCH v5 2/4] rust: sync: atomic: add atomic_per_byte_memcpy Andreas Hindborg
2026-11-11 14:46   ` sashiko-bot
2026-11-11 19:43     ` Andreas Hindborg
2026-11-10 14:44 ` [PATCH v5 3/4] rust: io: copy `SysMem` with `atomic_per_byte_memcpy` Andreas Hindborg
2026-11-10 14:44 ` [PATCH v5 4/4] rust: page: add byte-wise atomic copy methods for `SysMem` Andreas Hindborg
2026-11-11  9:30 ` [PATCH v5 0/4] rust: byte-wise atomic copies between `Page` and shared memory Peter Zijlstra
2026-11-11 13:26   ` Andreas Hindborg

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=sashiko-outbox-209186@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=liam@infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=lossin@kernel.org \
    --cc=lyude@redhat.com \
    --cc=mark.rutland@arm.com \
    --cc=ojeda@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=will@kernel.org \
    --cc=work@onurozkan.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