public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 19:49:22 +0100	[thread overview]
Message-ID: <DGSISB2SQHWM.D8OGH4JJHIRP@kernel.org> (raw)
In-Reply-To: <DGSDOKRKSKQL.2NQL17J05GGX2@garyguo.net>

On Mon Mar 2, 2026 at 3:49 PM CET, Gary Guo wrote:
> On Mon Mar 2, 2026 at 2:38 PM GMT, Benno Lossin wrote:
>> On Mon Mar 2, 2026 at 2:02 PM CET, Gary Guo wrote:
>>> +/// 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.
>
> The "in bounds" here is the conceptual bounds of the pointer. So, for a pointer
> with size `x`, the address of the returned pointer lies between `ptr .. ptr +
> x`.

Okay, I haven't really seen that as a concept. Also, what is the size of
an invalid pointer?

>> 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
>
> I have a `KnownSize` trait for this in my I/O projection series that is
> implemented for `T: Sized` and `[T]`, and it returns the size when given a raw
> pointer.
>
>>
>> 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.
>
> Given that I'm not introducing `KnownSize` trait in this patch, this is why I
> haven't used this kind of wording. Perhaps I can just bring `KnownSize` in early
> and use it first for documentation purpose only?

That sounds great.

>> Or something simpler that says "if the input pointer is valid, then
>> `get` must return a valid output pointer"?
>
> Hmm, wouldn't this give impression that "you can do whatever you want if the
> input pointer is not valid"?

Yes that's true, but why is that a problem?

>>> +#[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`?
>
> I'm following the name on `SliceIndex`:
> https://doc.rust-lang.org/stable/std/slice/trait.SliceIndex.html.

Hmm, the methods in that trait are marked as unstable under
`slice_index_methods`, which doesn't have a tracking issue, so are
perma-unstable? I'll suggest the rename upstream as well.

Cheers,
Benno

  reply	other threads:[~2026-03-02 18:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260302130223.134058-1-gary@kernel.org>
2026-03-02 13:02 ` [PATCH v3 1/2] rust: add projection infrastructure Gary Guo
2026-03-02 14:38   ` Benno Lossin
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 [this message]
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 14:42   ` [PATCH v3 2/2] rust: dma: use pointer projection infra for `dma_{read, write}` macro 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=DGSISB2SQHWM.D8OGH4JJHIRP@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox