From: "Benno Lossin" <lossin@kernel.org>
To: "Gary Guo" <gary@garyguo.net>, "Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nicolas Schier" <nsc@kernel.org>
Cc: <rust-for-linux@vger.kernel.org>,
"Aditya Rajan" <adi.dev.github@gmail.com>,
<linux-kernel@vger.kernel.org>, <linux-kbuild@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] rust: add projection infrastructure
Date: Mon, 02 Mar 2026 15:38:41 +0100 [thread overview]
Message-ID: <DGSDGDIVUHO0.P594H9B4LLO5@kernel.org> (raw)
In-Reply-To: <20260302130223.134058-2-gary@kernel.org>
On Mon Mar 2, 2026 at 2:02 PM CET, Gary Guo wrote:
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index 3da92f18f4ee..50866b481bdb 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -20,6 +20,7 @@
> #![feature(generic_nonzero)]
> #![feature(inline_const)]
> #![feature(pointer_is_aligned)]
> +#![feature(slice_ptr_len)]
This is missing a stability comment (stable since 1.79).
> //
> // Stable since Rust 1.80.0.
> #![feature(slice_flatten)]
...
> +/// A helper trait to perform index projection.
> +///
> +/// This is similar to `core::slice::SliceIndex`, but operate on raw pointers safely and fallibly.
> +///
> +/// # Safety
> +///
> +/// `get` must return a pointer in bounds of the provided pointer.
This only makes sense when the provided pointer already points at an
allocation. But since the functions of this trait aren't `unsafe`, it
must be sound to pass `ptr::null` to them.
I first thought that we might be able to just use `mem::size_of_val_raw`
[1] to give an upper and lower bound on the address of the returned
pointer, but that is unsafe and cannot be called with an arbitrary
pointer. Interestingly, `ptr::metadata` [2] can be called safely & with
any pointer; I would expect them to be very similar (except of course
for extern types).
[1]: https://doc.rust-lang.org/std/mem/fn.size_of_val_raw.html
[2]: https://doc.rust-lang.org/std/ptr/fn.metadata.html
A pretty expensive solution would be to add a sealed trait `Indexable`
that we implement for all things that `T` is allowed to be; and then we
provide a safe function in that trait to query the maximum offset the
`get` function is allowed to make.
Alternatively, we could use something like this:
The implementation of `get` must:
- return a pointer obtained by offsetting the input pointer.
- ensure that when the input pointer points at a valid value of type
`T`, the offset must not be greater than [`mem::size_of_val_raw`]
of the input pointer.
Or something simpler that says "if the input pointer is valid, then
`get` must return a valid output pointer"?
> +#[diagnostic::on_unimplemented(message = "`{Self}` cannot be used to index `{T}`")]
> +#[doc(hidden)]
> +pub unsafe trait ProjectIndex<T: ?Sized>: Sized {
> + type Output: ?Sized;
> +
> + /// Returns an index-projected pointer, if in bounds.
> + fn get(self, slice: *mut T) -> Option<*mut Self::Output>;
How about we name this `try_index` instead of the general `get`?
> +
> + /// Returns an index-projected pointer; fail the build if it cannot be proved to be in bounds.
> + #[inline(always)]
> + fn index(self, slice: *mut T) -> *mut Self::Output {
> + Self::get(self, slice).unwrap_or_else(|| build_error!())
> + }
> +}
...
> +/// A helper trait to perform field projection.
> +///
> +/// This trait has a `DEREF` generic parameter so it can be implemented twice for types that
> +/// implement `Deref`. This will cause an ambiguity error and thus block `Deref` types being used
> +/// as base of projection, as they can inject unsoundness.
I think it's important to also say that the ambiguity error only happens
when calling the function without specifying the `DEREF` constant.
Essentially it is a load-bearing part of the macro that it does this.
> +///
> +/// # Safety
> +///
> +/// `proj` should invoke `f` with valid allocation, as documentation described.
s/should invoke `f` with/may invoke `f` only with a/
"should" sounds like only a suggestion. If it is a requirement, then the
`build_error!` impl of the `DEREF = true` case would be violating it.
> +#[doc(hidden)]
> +pub unsafe trait ProjectField<const DEREF: bool> {
> + /// Project a pointer to a type to a pointer of a field.
> + ///
> + /// `f` is always invoked with valid allocation so it can safely obtain raw pointers to fields
> + /// using `&raw mut`.
> + ///
> + /// This is needed because `base` might not point to a valid allocation, while `&raw mut`
> + /// requires pointers to be in bounds of a valid allocation.
> + ///
> + /// # Safety
> + ///
> + /// `f` must returns a pointer in bounds of the provided pointer.
Typo: "must returns" -> "must return"
Cheers,
Benno
> + unsafe fn proj<F>(base: *mut Self, f: impl FnOnce(*mut Self) -> *mut F) -> *mut F;
> +}
next prev parent reply other threads:[~2026-03-02 14:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 13:02 [PATCH v3 0/2] rust: add pointer projection infrastructure and convert DMA Gary Guo
2026-03-02 13:02 ` [PATCH v3 1/2] rust: add projection infrastructure Gary Guo
2026-03-02 14:38 ` Benno Lossin [this message]
2026-03-02 14:48 ` Danilo Krummrich
2026-03-02 18:49 ` Benno Lossin
2026-03-02 14:49 ` Gary Guo
2026-03-02 18:49 ` Benno Lossin
2026-03-02 20:14 ` Gary Guo
2026-03-02 22:01 ` Benno Lossin
2026-03-02 22:19 ` Gary Guo
2026-03-03 9:14 ` Benno Lossin
2026-03-03 10:17 ` Gary Guo
2026-03-03 11:39 ` Alice Ryhl
2026-03-03 12:21 ` Gary Guo
2026-03-02 13:02 ` [PATCH v3 2/2] rust: dma: use pointer projection infra for `dma_{read,write}` macro Gary Guo
2026-03-02 13:02 ` [PATCH v3 2/2] rust: dma: use pointer projection infra for `dma_{read, write}` macro Gary Guo
2026-03-02 14:42 ` Benno Lossin
2026-03-02 14:42 ` Benno Lossin
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=DGSDGDIVUHO0.P594H9B4LLO5@kernel.org \
--to=lossin@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=adi.dev.github@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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.