Re: [PATCH v3 1/2] rust: add projection infrastructure

["Benno Lossin" <lossin@kernel.org>]

On Mon Mar 2, 2026 at 9:14 PM CET, Gary Guo wrote:
> On Mon Mar 2, 2026 at 6:49 PM GMT, Benno Lossin wrote:
>> 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?
>
> It's `size_of::<T>()` for sized types, and `size_of::<T>() * slice.len()` for a
> raw slice pointer.

And for `dyn Trait`?

Do you have a link to somewhere?

> The projection semantics is same regardless whether it's valid or not. The I/O
> projection work will rely on this, as many I/O impls will act on pointers that
> are not "valid" in Rust sense because they refer to a different address space.
> But they're still legit pointers with proper meaning.

I like the solution with `KnownSize`. The previous safety requirement
was nebulous IMO.

>>>> 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?
>
> A impl that returns an arbitrary pointer when given a null pointer is not valid.
>
> I/O projection will use the ability to project on null pointers, too. An example
> is PCI config space code, which will project using null pointer as starting
> pointer.
>
> The "bounds" projected pointer must still be with in `0..KnownSize::size(ptr)`.

I would not have assumed this to be valid with the previous comment.

Cheers,
Benno