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 7DD16CDE001 for ; Thu, 26 Sep 2024 13:24:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFC746B0095; Thu, 26 Sep 2024 09:24:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAC396B0096; Thu, 26 Sep 2024 09:24:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D74286B0098; Thu, 26 Sep 2024 09:24:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BAE916B0095 for ; Thu, 26 Sep 2024 09:24:48 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 37D75ACED7 for ; Thu, 26 Sep 2024 13:24:48 +0000 (UTC) X-FDA: 82606959456.18.8E56980 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf18.hostedemail.com (Postfix) with ESMTP id 89E621C0006 for ; Thu, 26 Sep 2024 13:24:46 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Cg1USL/m"; spf=pass (imf18.hostedemail.com: domain of dakr@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727357050; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=L9LTTyzsOVinuzBc+NDcLg4ExD7eOb2K1M3RwAKYwn8=; b=yzmIBT9+W64/Im+V21MYf5ZSz/4ePMpodK09DMbUm0X8SwRN9Y5cjhXqX5URzRpRpVGlj7 qNAAKvNmzEa4oh8KYdwCbm4PbeHpnKdqF518T/yQ6AXJFgkvTgZtShNn3GsjJRZBKSjtk8 MyINoYyyuyz23F6P5f946/sx94QsJ70= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Cg1USL/m"; spf=pass (imf18.hostedemail.com: domain of dakr@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727357050; a=rsa-sha256; cv=none; b=oWNgGyOZdG1vxbracqh1Gc2Vek0Ux5NhQN76lb7H2kc7L/d1rHSW9634dJxa1ztvE1oGQn Cte/FhM2ADCHRpYK6mE1Q86PWUV6qus2L72Nh2SEwLrlHIEepB7q3++oE0Feny7Acs9bok 17M9Xw1akglAT5WK+dRmlnWFnjJqUBY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 797C7A44CD2; Thu, 26 Sep 2024 13:24:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07F14C4CEC5; Thu, 26 Sep 2024 13:24:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1727357085; bh=Ev17E6HPXrIHJ7KiVzlg4fQjIPKFzPlo86lB1LBlExk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Cg1USL/mXifPqA4Z1NOvsq+zHXfVpI2bTeRIDkUWo2bABYniXHcmWIUt9ViZCHysJ DxFBnIXXo9OuWcRNmcSlp7YGQFemv2X5g3k72HpE9i8uKNXAzmRthE9eeu3JAhHX// aOPtGZ7vxPtoTgC5sxiXml54vy8MuMx/6SPPqUYM2kupjT+7ta1NcsaXdbtZOQ/sW+ TkW/tB7jhX2Q1mCWVL4c9I4P7tvMGcwz6VlVK1B/oyGxAaP8oMgkIoLMmd3/xkZP9Q 2jPmsE0J+pkjLrMx/4/+AVP77eBj4d/p10+60+wQpPGZDRXD8F/x0W1/ZAKy8NGOcn aMGI/5y2gYzHQ== Date: Thu, 26 Sep 2024 15:24:26 +0200 From: Danilo Krummrich To: 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 v7 04/26] rust: alloc: implement `Allocator` for `Kmalloc` Message-ID: References: <20240911225449.152928-1-dakr@kernel.org> <20240911225449.152928-5-dakr@kernel.org> <15f42ddd-b011-4136-b2e4-bc266fab25b6@proton.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15f42ddd-b011-4136-b2e4-bc266fab25b6@proton.me> X-Rspam-User: X-Stat-Signature: 3roueiypipiby6xtbzg9bghd8zthztm8 X-Rspamd-Queue-Id: 89E621C0006 X-Rspamd-Server: rspam11 X-HE-Tag: 1727357086-409706 X-HE-Meta: U2FsdGVkX19bulHBiPj6/5563EarpYwEmGAalevqZFH3Zcl6Y43AKPyw0dFVGBo3o2ghd+vRh497y6l6SpoOIl9oSSeaFvtUEA90HuqF4amDj708/2fW4Rc7ibLC7fMot13+xc15mMwkybgpxNcjvMhIH2KfQHpXnauarT27a6yZpXzFeiUWWJWNkhw22coil2ddc0P9bzpDv1oTPbGAF2W5UAZ0AOnorDbr3sqtLoreld0A8dr34Pnr5eCbVUJmBF1mYESm9W6PFIKnjasLFMEu2ZiQWxFXuUrgQOeudq0TV/BhhwmvqL83CBrcc7NtV80B+Acn/Sshl2bh79FMu/UCw3sw1C6OzdVRR/jAevDNOwGFfKGR+ecNOkKzDJ03/7qMmrfr5d4bw3ojqEHOvM1bsjQZopkwMPhTH8Uq/i/T8TX69v53EVvoQePqrI8yMc86dqfj1SifHyyWMF4zTmrzMhZdCZzanjRBDiYY+oJr8ZitBgLIuyL124B9vUgq3Zu5OKqbc/orljdxiY4GDxwpSD6m3dyVbrPl78jdDtWJ7EFG4uatVHYZ9RX+EMD66pMard4Dg4CsAxqz2smsAH2sn6jtugnG+Fj7/4MMpUZM5CwKd7vWKZLDDRcpzNYWXOeLhhz3vcZHJX1M6N4Tusa0iu6atOJPeQg6hdKKuKhFTNk7HkDVeupd+ngrfGYRI/ow0NNAGma4xXZN3+fzzhweLj3TSzqk0vS//p7n5fc7Y6FcNR0yBb/fFJWf3mVKMc9+fDbz1O96Y4C3KR/Bp72yfWITOXNPQVlvCGcmnmfcrfSUmbUDNHpw7HzV01BIs54ARQZai+/Rb7FbtX0P3qNDiSbv1uWTisEPoV4kCTvGjWgK12KfOhOfnQ0EkXw9yvTRrx/YjbwlA7RpnwlHd99Xvs4GyKbfV+VrFMOCqzHcpyErw5lKfFE0dQYg9sQiY6eB1Fjp4xcWQ36N8Dw LFICd8Zv In+IjlKSgQRHQII/cbVpJTJ3vOM0MDuiBzxykz3W8H8xxlb77H6bajyGAdh3LcG8Jk837CT78w8kxljOqU0X2gVvj+yeYR8D9frPviCWtBDMwfIYUzGFUxjzUjz3KF/cn961HImcb8GZPCAkcff5UNc1Bj9jBFVQTJLB2JP1xYFLd6rJofhlqx9MYTWbi3ysPfTzungREBH0ov5oyawQVRUq+2NdjadPQusGkSfbjBKUvGHg8bV7tH9t8+UpFzQLvUxz8x9oRESQHt1JR2q+6ZSINhAALeN3GdCfLZdKXhmz3jy3t5M7WoViq6/df/LQOIJoCMj4TgXNdkHY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000017, 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 Thu, Sep 26, 2024 at 01:00:58PM +0000, Benno Lossin wrote: > On 12.09.24 00:52, Danilo Krummrich wrote: > > +/// # 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 = Self(bindings::krealloc); > > + > > + /// # Safety > > + /// > > + /// This method has the same safety requirements as [`Allocator::realloc`]. > > + /// > > + /// # Guarantees > > + /// > > + /// This method has the same guarantees as `Allocator::realloc`. Additionally > > + /// - it accepts any pointer to a valid memory allocation allocated by this function. > > + /// - memory allocated by this function remains valid until it is passed to this function. > > + unsafe fn call( > > + &self, > > + ptr: Option>, > > + layout: Layout, > > + flags: Flags, > > + ) -> Result, AllocError> { > > + let size = aligned_size(layout); > > + let ptr = match ptr { > > + Some(ptr) => ptr.as_ptr(), > > + None => ptr::null(), > > + }; > > + > > + // SAFETY: > > + // - `self.0` is one of `krealloc`, `vrealloc`, `kvrealloc` and thus only requires that > > + // `ptr` is NULL or valid. > > + // - `ptr` is either NULL or valid by the safety requirements of this function. > > + // > > + // GUARANTEE: > > + // - `self.0` is one of `krealloc`, `vrealloc`, `kvrealloc`. > > + // - Those functions provide the guarantees of this function. > > + let raw_ptr = unsafe { > > + // If `size == 0` and `ptr != NULL` the memory behind the pointer is freed. > > + self.0(ptr.cast(), size, flags.0).cast() > > + }; > > + > > + let ptr = if size == 0 { > > + NonNull::dangling() > > + } else { > > + NonNull::new(raw_ptr).ok_or(AllocError)? > > + }; > > + > > + Ok(NonNull::slice_from_raw_parts(ptr, size)) > > + } > > +} > > I remember asking you to split this into a different commit. I think you > argued that it would be better to keep it in the same commit when > bisecting. I don't think that applies in this case, are there any other > disadvantages? I don't really like the intermediate `#[expect(dead_code)]`, plus it's additional work you didn't really give me a motivation for, i.e. you did not mention what would be the advantage. But sure, I will change it for the next version. > > --- > Cheers, > Benno > > > + > > +// SAFETY: `realloc` delegates to `ReallocFunc::call`, which guarantees that > > +// - memory remains valid until it is explicitly freed, > > +// - passing a pointer to a valid memory allocation is OK, > > +// - `realloc` satisfies the guarantees, since `ReallocFunc::call` has the same. > > +unsafe impl Allocator for Kmalloc { > > + #[inline] > > + unsafe fn realloc( > > + ptr: Option>, > > + layout: Layout, > > + flags: Flags, > > + ) -> Result, AllocError> { > > + // SAFETY: `ReallocFunc::call` has the same safety requirements as `Allocator::realloc`. > > + unsafe { ReallocFunc::KREALLOC.call(ptr, layout, flags) } > > + } > > +} > > > > + > > unsafe impl GlobalAlloc for Kmalloc { > > unsafe fn alloc(&self, layout: Layout) -> *mut u8 { > > // SAFETY: `ptr::null_mut()` is null and `layout` has a non-zero size by the function safety > > -- > > 2.46.0 > > >