From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 3E4571FF0AA for ; Mon, 07 Sep 2026 15:40:20 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id BE1F3214FF; Mon, 07 Sep 2026 15:40:19 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 07 Sep 2026 15:40:13 +0200 Message-Id: To: "Robert Obkircher" From: "Max R. Carrara" Subject: Re: [PATCH proxmox v2 01/10] proxmox-alloc: introduce proxmox-alloc with `LayoutAwareBox` type X-Mailer: aerc 0.18.2-0-ge037c095a049 References: <20260821140238.615302-1-m.carrara@proxmox.com> <20260821140238.615302-2-m.carrara@proxmox.com> <178836567690.287871.2706501273479858915.b4-review@b4> <4943f2e3-8bba-4388-b2c7-f7f714044208@proxmox.com> In-Reply-To: <4943f2e3-8bba-4388-b2c7-f7f714044208@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788788406994 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.603 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 5W3PSSWY6L6GGB5UUQN2RKIJKWLO5WQO X-Message-ID-Hash: 5W3PSSWY6L6GGB5UUQN2RKIJKWLO5WQO X-MailFrom: m.carrara@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pbs-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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`] from a pointer and a [`La= yout`]. > >>> + /// > >>> + /// Note that if `T` is [zero-sized], no allocation is actually = performed. > >>> + /// > >>> + /// # Safety > >>> + /// > >>> + /// Improper use of this function can lead to [undefined behavio= r] 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 pa= ssed 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 `1= 024` bytes > >>> + /// for a struct that only takes up `1000` bytes for some reason= , > >>> + /// deallocating this struct will *still* be considered undefine= d 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/656a9da186dacaf3bf8f7f7296a825d256= cb4ae3/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 onl= y > >> 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/656a9da186dacaf3bf8f7f7296a825d256= cb4ae3/library/alloc/src/vec/spec_from_elem.rs#L24 Ah, thanks for the link! > > > [..]