Re: [PATCH proxmox v2 01/10] proxmox-alloc: introduce proxmox-alloc with `LayoutAwareBox<T>` type

["Max R. Carrara" <m.carrara@proxmox.com>]

On Mon Sep 7, 2026 at 2:50 PM CEST, Robert Obkircher wrote:
>
> On 07.09.26 13:44, Max R. Carrara wrote:
> >>> [..]
> >>>
> >>> +
> >>> +    /// Create a new [`LayoutAwareBox<T>`] from a pointer and a [`Layout`].
> >>> +    ///
> >>> +    /// Note that if `T` is [zero-sized], no allocation is actually performed.
> >>> +    ///
> >>> +    /// # Safety
> >>> +    ///
> >>> +    /// Improper use of this function can lead to [undefined behavior] and other
> >>> +    /// issues.
> >>> +    ///
> >>> +    /// In general, the same safety requirements as for [`Box::from_raw`] apply
> >>> +    /// for this function.
> >>> +    ///
> >>> +    /// **Additionally,** the caller must also guarantee that the passed pointer
> >>> +    /// points to a `T` which was allocated using the passed layout **and** has
> >>> +    /// the same size as its underlying allocation.
> >>> +    ///
> >>> +    /// The latter in particular is easy to miss: If you allocate `1024` bytes
> >>> +    /// for a struct that only takes up `1000` bytes for some reason,
> >>> +    /// deallocating this struct will *still* be considered undefined behavior
> >>> +    /// and will be spotted by [Miri].
> >> That reason might be pointer provenance. Once you shrink down the
> >> spacial memory range a pointer is allowed to access, you are not
> >> allowed to extend it back to the full size (see std::ptr module docs).
> >>
> >> Makes me wonder if this is even safe:
> >> ptr::slice_from_raw_parts_mut(thin_ptr, len) as *mut DST;
> >>
> >> I'll have to read up on this.
> > Hm, why would that call not be safe? Assuming the size / len
> > calculations are all correct etc.
> The call itself is definitely safe, the question is whether the result
> can be dereferenced.
> >
> > All that `ptr::slice_from_raw_parts_mut` does is say "there are `len`
> > elements in the (trailing) slice of `T` that `thin_ptr` points to" --
> > I'm not sure it affects the provenance of the pointer in this case..?
> >
> > Actually, reading up on [provenance] now, there's a paragraph that
> > mentions the following:
> >
> >> The Original Pointer for an allocation has provenance that constrains
> >> the spatial permissions of this pointer to the memory range of the
> >> allocation, and the temporal permissions to the lifetime of the
> >> allocation. Provenance is implicitly inherited by all pointers
> >> transitively derived from the Original Pointer through operations like
> >> offset, borrowing, and pointer casts.
> > The last sentence here I think is key, since *I think* that in this
> > context, `ptr::slice_from_raw_parts_mut` should be considered a pointer
> > cast, since it's a thin-to-fat conversion, only changing the pointer's
> > metadata. I therefore would say that this does not create new
> > provenance, since it only constrains the slice's valid range.
> I also think so.
> >
> > Then again, what pointer provenance is is not concretely defined yet
> > anyways, so I'm not sure if it's worth worrying over that...
> >
> > (Also, that pattern for DSTs is well-established in the ecosystem, tbf.)
> >
> > [provenance] https://doc.rust-lang.org/std/ptr/index.html#provenance
> >
> >>
> >> [..]
> >> +
> >> +        for i in 0..len {
> >> +            // SAFETY: thin_ptr is valid for writing and we never go out of
> >> +            // bounds during iteration.
> >> +            unsafe { thin_ptr.add(i).write(value.clone()) };
> >> +        }
> >>
> >> nit: this doesn't drop the previous elements if clone panics [...]
> > Oh, that's true actually. Thanks for pointing this out, will see how
> > I'll fix this in v2.
> To be clear: It is technically safe not to call drop.
> >
> >> [...] and there is an unnecessary copy in the last iteration.
> > What exactly do you mean?
> You call clone() n times instead of n-1. Not the end of the world, though.
>
> https://github.com/rust-lang/rust/blob/656a9da186dacaf3bf8f7f7296a825d256cb4ae3/library/alloc/src/vec/mod.rs#L3759

Oh, right! Damn, thanks for spotting this.

>
> >
> >> Couldn't this entire function just forward to slice_fill_with? The only
> >> insteresting special case is if `value` was all zeroes.
> > Hmm, I think it could, but I'll have to double-check.
> Unfortunately, the IsZero trait is not available outside of the alloc
> crate:
>
> https://github.com/rust-lang/rust/blob/656a9da186dacaf3bf8f7f7296a825d256cb4ae3/library/alloc/src/vec/spec_from_elem.rs#L24

Ah, thanks for the link!

>
> > [..]