From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83500EDE9B0 for ; Tue, 10 Sep 2024 19:43:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E6E3F8D00B2; Tue, 10 Sep 2024 15:43:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1D908D0002; Tue, 10 Sep 2024 15:43:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D33C28D00B2; Tue, 10 Sep 2024 15:43:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B0EBE8D0002 for ; Tue, 10 Sep 2024 15:43:05 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2B0F81A04A4 for ; Tue, 10 Sep 2024 19:43:05 +0000 (UTC) X-FDA: 82549851930.15.62E7EC2 Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) by imf09.hostedemail.com (Postfix) with ESMTP id 4D42E140003 for ; Tue, 10 Sep 2024 19:43:03 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=proton.me header.s=protonmail header.b=cRjU1mPe; spf=pass (imf09.hostedemail.com: domain of benno.lossin@proton.me designates 185.70.40.131 as permitted sender) smtp.mailfrom=benno.lossin@proton.me; dmarc=pass (policy=quarantine) header.from=proton.me ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725997281; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Us6VG5nQDdDxL5urD5Sho4IxwJbjQmA55je3Wx4UKTM=; b=ogqvWA/d90U0+s4K14XFjaF86LIT2giYRRsOqXpbNR4MQtS02aHX5CedsIWIlJYzcenUhr VBpUE28a/Ruzr/cFpOP1mq12XoEV7rfd4ZfdXN8ALsBCKI4M/brtRT33t+Ri+FzNCa76BX onL5IStf4+mAONcGgaLaeyqplNwRf38= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725997281; a=rsa-sha256; cv=none; b=PAl3Db+1WgFbRH9ihkWTnNUMXYepXNg5dgzuX8o49QGyPTHuzROYbcxz0S2Ot7kv7HQtHb Q0IPa1vGVnUMG0vizBQp9EpLVdtgy3BJAfx9Sd22vQf2SlZHCjkSiUXsKCmbcQrFELNmDd eb2+1YZGpUC/QsYFhnSciaj2loZyzuQ= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=proton.me header.s=protonmail header.b=cRjU1mPe; spf=pass (imf09.hostedemail.com: domain of benno.lossin@proton.me designates 185.70.40.131 as permitted sender) smtp.mailfrom=benno.lossin@proton.me; dmarc=pass (policy=quarantine) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1725997381; x=1726256581; bh=Us6VG5nQDdDxL5urD5Sho4IxwJbjQmA55je3Wx4UKTM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=cRjU1mPefQYidYLc2FHqC23tY/cq/DraTfUuUu+j6KF6KRZqrbLJLWzGTCX3br1ZB Tx7zRCuTXovxyh+Z5PmZ6twptgWvVsRFduJwNwLlrQtkC/deZv0gv0udGblD3qBzpl nptWS+Nw2vi6xRLtyMUO86Sdhp1ZQo18EATHtnvZCHkHVz5Tzp6kJXyg0ZyRkqB991 GqsbekkADqjESz3RXmB0Z30Z+IR2rSVAAO69bD2K4CkcwBXjvmi3dNEVg51fDgK1DI epDDhS+Xhn/gkWjCX9KEa9HFFcstwk2UHy52E/F0qdefrxQls1GoHIintejdf5wLJq i+1U/7s5LYqJQ== Date: Tue, 10 Sep 2024 19:42:58 +0000 To: Danilo Krummrich From: Benno Lossin Cc: ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, a.hindborg@samsung.com, aliceryhl@google.com, akpm@linux-foundation.org, daniel.almeida@collabora.com, faith.ekstrand@collabora.com, boris.brezillon@collabora.com, lina@asahilina.net, mcanal@igalia.com, zhiw@nvidia.com, cjia@nvidia.com, jhubbard@nvidia.com, airlied@redhat.com, ajanulgu@redhat.com, lyude@redhat.com, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v6 04/26] rust: alloc: implement `Allocator` for `Kmalloc` Message-ID: <92ef0fb2-aa5a-451a-a79c-2d81e562da41@proton.me> In-Reply-To: References: <20240816001216.26575-1-dakr@kernel.org> <20240816001216.26575-5-dakr@kernel.org> <2dd02834-b2b6-4ff6-9e29-43c9d77b69e2@proton.me> <962b7014-4f8b-4abe-8774-636b612a051c@proton.me> Feedback-ID: 71780778:user:proton X-Pm-Message-ID: d22009bd5d0f6c20035602ec26b4f558f839fd62 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4D42E140003 X-Stat-Signature: nrwm1zeruia13en377fuieybtfmcoant X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1725997383-72322 X-HE-Meta: U2FsdGVkX18CTFiGDfDP2736Ds3LzLpQOJsdhIgvLteOcLbNg1EM7i1xaon+qvEWpWVKWK0cc/f/O0lIfG2IYVUCq2ceh0v3SdkFVH9ZvglJLC9su4X/R7wUL5kzdhh5ZvYq//RpVPMDWRREn/xoDQsfIdICAL6LzcVISlFgNXMKsohriySqUkLhw+ZnRypYlWiEiglC1bwBgLfjJDFzIOxSEUyGQod5xVUhCC7wAM0uL45R+bZNzpGQKoik1tjAP6inQbo0UTPgI4nltscJHNEXL1MnYlttpVSfiRtmy8xh/CXcihUnL+Bx8RF/7CS65AN3kGoS7Bn/5IKCQsFhFhEM70Tp3NGEAOjL8HV5vQmP0xuvbqkBrKbuT6S4dTHp7OrvvamVQPwH4dMBY8sGipk64H0X3FddPHOFO3n7CqTme1rgFwSWWSUSKDuLmeiWDZMoi3VzfuyiqALCF9REZ54l+iQOFN48cLzDznzfZCDiqRJIvof7lsNTVvVuJ1TNMo7b1uVLuWTQCE/ratWoz6A99GOxaBJ3xs3jYtqiLO1pmbhzsAdy40TuG+3YT5bQcquxLrdvOJaUoMhtxsjmzaJaJ27qahaI4WKFu4DeDp7WPe8IZ5IJ7PXZxF/7JufptwhBltOnWhfnfsGQgphEqbZ/jiJjhiEebUmKJsxbSNuFS8Lhr7KBDbO/Jdj8J/2pqnbUiGXnziBoWdHOUzYGrDCtYqdsPmI1VEx4cLZ1dloAnRx/wVPMba7JwTHVEjGWB8R8sCKXP2x22+FVrt+Z3tXjpU+l+f6GeEqYPNWlBSzt/pFOeeBaNIUL7ObN3xCNSt5xgYJZ6Rf7UmBbS8zWaPu4JlJuGj6b7h7ZU+86ZLguLWB3ZRKFAXGCLUamU0UBlPXk2jTLuOWQ8Lr/rHiT7fbeeb1BZN3a9njf2aIP2wFkNfY0PnYuZzbFGcl083dTzycEUXRV3LMLK2MriMY abOPiJwZ 9SCEdaN+kG3LgDF1ruheRC8lvm0/B7nSEbcsC0prCkAzgGmFAtDLDTZkBvzpAwedcP458kxHiR+glx5WgT7/MXP/UdXLvuy52Gx5D9Mr/DU82gkqDgePNERrK2a4XS+o3MXltixWjyHs4YaCwIBe1DEpxiEM3TEcFGkGgafVpS3wL1i11hLigI44+XV6NsMMcxauIZ3+OLsed4Mv4G4zwqzAfrLxFs3itXPcajO4lEhu0CwPplmEvtRm6FkYrt0C79bkoHYT1gEIPe70MzJQE5BSxUTphCRDnEsWqrSb3PDVv4cM1bxIyfbaCVVs3eYs/NDjMk/4b1rGfjPRDhclSnC9b6roWlQLw1aO5+DdkN0hKMmvRTE43pnFF2LxLNAuNdJ8t X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 10.09.24 15:37, Danilo Krummrich wrote: > On Tue, Sep 10, 2024 at 01:11:35PM +0000, Benno Lossin wrote: >> On 03.09.24 13:48, Danilo Krummrich wrote: >>> On Fri, Aug 30, 2024 at 02:45:35PM +0000, Benno Lossin wrote: >>>> On 30.08.24 00:04, Danilo Krummrich wrote: >>>>> On Thu, Aug 29, 2024 at 06:32:42PM +0000, Benno Lossin wrote: >>>>>> On 16.08.24 02:10, Danilo Krummrich wrote: >>>>>>> +/// >>>>>>> +/// For more details see [self]. >>>>>>> +pub struct Kmalloc; >>>>>>> >>>>>>> /// Returns a proper size to alloc a new object aligned to `new_la= yout`'s alignment. >>>>>>> fn aligned_size(new_layout: Layout) -> usize { >>>>>>> @@ -36,6 +52,60 @@ pub(crate) unsafe fn krealloc_aligned(ptr: *mut = u8, new_layout: Layout, flags: F >>>>>>> unsafe { bindings::krealloc(ptr as *const core::ffi::c_void, s= ize, flags.0) as *mut u8 } >>>>>>> } >>>>>>> >>>>>>> +/// # Invariants >>>>>>> +/// >>>>>>> +/// One of the following `krealloc`, `vrealloc`, `kvrealloc`. >>>>>>> +struct ReallocFunc( >>>>>>> + unsafe extern "C" fn(*const core::ffi::c_void, usize, u32) -> = *mut core::ffi::c_void, >>>>>>> +); >>>>>>> + >>>>>>> +impl ReallocFunc { >>>>>>> + // INVARIANT: `krealloc` satisfies the type invariants. >>>>>>> + const KREALLOC: Self =3D Self(bindings::krealloc); >>>>>>> + >>>>>>> + /// # Safety >>>>>>> + /// >>>>>>> + /// This method has the same safety requirements as [`Allocato= r::realloc`]. >>>>>>> + unsafe fn call( >>>>>>> + &self, >>>>>>> + ptr: Option>, >>>>>>> + layout: Layout, >>>>>>> + flags: Flags, >>>>>>> + ) -> Result, AllocError> { >>>>>>> + let size =3D aligned_size(layout); >>>>>>> + let ptr =3D match ptr { >>>>>>> + Some(ptr) =3D> ptr.as_ptr(), >>>>>>> + None =3D> ptr::null(), >>>>>>> + }; >>>>>>> + >>>>>>> + // SAFETY: `ptr` is either NULL or valid by the safety req= uirements of this function. >>>>>> >>>>>> You need some justification as to why calling the three allowed >>>>>> functions here. >>>>> >>>>> What kind of justification do I need? Can you please share some more = details on >>>>> what you think is missing here? >>>> >>>> So, you are calling a function pointer to an `unsafe` function. This >>>> means that through some invariant you have to know what the safety >>>> requirements are (otherwise how can you guarantee that this is OK?). Y= ou >>>> have the invariant that the pointer points at one of the three functio= ns >>>> mentioned above. What are the safety requirements of those functions? = I >>>> would assume that the only one is that `ptr` is valid. So you can use: >>>> >>>> // SAFETY: >>>> // - `self.0` is one of `krealloc`, `vrealloc`, `kvrealloc` and th= us only requires that `ptr` is >>>> // NULL or valid. >>> >>> I'm fine adding it, but I'd like to understand why you think it's requi= red in >>> the safety comment here? Isn't this implicit by being the type invarian= t? >> >> You are calling a function pointer to an `unsafe` function that takes a >> raw pointer. Without this comment it is not clear what the function >> pointer's safety requirements are for the raw pointer parameter. >=20 > That's my point, isn't this implicitly clear by the type invariant? If ne= eded, > shouldn't it be: I would argue that it is not implicitly clear, since to the reader of just that unsafe block it's totally unclear that `self.0` has such an invariant. They would have to read the type definition. > // INVARIANT: > // - `self.0` is one of [...] > // > // SAFETY: > // - `ptr` is either NULL or [...] >=20 >> >>>> // - `ptr` is either NULL or valid by the safety requirements of t= his function. >>> >>> This is the part I already have. >> >> I kept it to ensure that you also keep it. [...] >>>>>>> + #[inline] >>>>>>> + unsafe fn realloc( >>>>>>> + ptr: Option>, >>>>>>> + layout: Layout, >>>>>>> + flags: Flags, >>>>>>> + ) -> Result, AllocError> { >>>>>>> + // SAFETY: `ReallocFunc::call` has the same safety require= ments as `Allocator::realloc`. >>>>>>> + unsafe { ReallocFunc::KREALLOC.call(ptr, layout, flags) } >>>>>>> + } >>>>>>> +} >>>> >>>> Oh one more thing, I know that you already have a lot of patches in th= is >>>> series, but could you split this one into two? So the first one should >>>> introduce `ReallocFunc` and the second one add the impl for `Kmalloc`? >>>> I managed to confuse me twice because of that :) >>> >>> Generally, I'm fine with that, but I'm not sure if I can avoid an inter= mediate >>> compiler warning about unused code doing that. >> >> You can just use `#[expect(dead_code)]` for that in the intermediate >> patches. >=20 > I usually try to avoid that, because it can be misleading when bisecting = things. >=20 > If the temporarily unused code contains a bug, your bisection doesn't end= up at > this patch, but some other patch that starts using it. I don't think it's a problem in this case, since the two patches are directly next to each other and you're not changing existing code, just splitting up the addition of new code. --- Cheers, Benno