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 B93921FF0AA for ; Mon, 07 Sep 2026 14:50:11 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 5B8E92153C; Mon, 07 Sep 2026 14:50:11 +0200 (CEST) Message-ID: <4943f2e3-8bba-4388-b2c7-f7f714044208@proxmox.com> Date: Mon, 7 Sep 2026 14:50:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH proxmox v2 01/10] proxmox-alloc: introduce proxmox-alloc with `LayoutAwareBox` type To: "Max R. Carrara" References: <20260821140238.615302-1-m.carrara@proxmox.com> <20260821140238.615302-2-m.carrara@proxmox.com> <178836567690.287871.2706501273479858915.b4-review@b4> Content-Language: en-US, de-AT From: Robert Obkircher In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788785399970 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.600 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: 5ZYWQDU6BAYBAZQPZWBFRHRTGBUPFYYQ X-Message-ID-Hash: 5ZYWQDU6BAYBAZQPZWBFRHRTGBUPFYYQ X-MailFrom: r.obkircher@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 07.09.26 13:44, Max R. Carrara wrote: >>> [..] >>> >>> + >>> + /// Create a new [`LayoutAwareBox`] 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 > >> 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 > [..]