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 B8769C77B7F for ; Fri, 27 Jun 2025 11:20:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 47CBC6B00C1; Fri, 27 Jun 2025 07:20:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 42A616B00C2; Fri, 27 Jun 2025 07:20:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33F156B00C3; Fri, 27 Jun 2025 07:20:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1ED5A6B00C1 for ; Fri, 27 Jun 2025 07:20:19 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A2F3E1215D9 for ; Fri, 27 Jun 2025 11:20:18 +0000 (UTC) X-FDA: 83600936916.17.E4A5941 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf25.hostedemail.com (Postfix) with ESMTP id D8B17A0003 for ; Fri, 27 Jun 2025 11:20:16 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hl8+5wB9; spf=pass (imf25.hostedemail.com: domain of dakr@kernel.org designates 172.234.252.31 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=1751023217; 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=IUor7N4wOzDY6TdiU1rgASuj/X5YBTSw0Ioc2bKQMfc=; b=DDUBBWEsuCustnj6QSKkLnl4ugZwO32XJReEAz/il2DCaUpQUf5HuMAV/fg08+6On6amAq niRBWvMhIHvNTgtu/WZYejQsB+CgJlLuQvaBKLj4uW4udqUcxzPNXk+ZaziwpgaWYlYubB /va2vHvq9EuKhhHvl9uoKFYUWNEIC9Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751023217; a=rsa-sha256; cv=none; b=pmNg8osnUtzq5k8if99ZYY9+pVl2NqzXH5Bp5ewt5V9gMpuL1/jDox7F8XPkCB3KuTGMR9 LKIh5eoW7diVzOeLC9867a1XzS+LyKwTUpCS7ZPbCRfEbVxftIvIlKPD3bZ7NJMYAoHbtL IjsW1FNQ1OW0u9x41SZAK6za9grpWXI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hl8+5wB9; spf=pass (imf25.hostedemail.com: domain of dakr@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 795C845D10; Fri, 27 Jun 2025 11:20:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC69FC4CEE3; Fri, 27 Jun 2025 11:20:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751023215; bh=LlMs2RYEoSyATnOfokVMPOkgG73vQ701gJIshNUkVJE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hl8+5wB9xLillD0nK5nrroF9IjtyhcV9bEzcfVOKQ7snWYDSS9iMEzqcYqPdxWBYj S1almeYH4kttJ/ukqfYDBdBhNnxLht1FdZktgJs9qC208XhrUv62g04yzzja0WPRAS neT4NtjNIHTTkblM7jebiaqNyLodx9EiZJTH54xrO9TVDECslDQHPEmvZHmqi9pcSf F016Zu+XO3wd9LYPdWOAJ1U/TOQGMb3fQx2pSlyDChp8gKvfkSoFTfijRsdTr16Nhh /Nq6yocw77YZUh3++gbRX/3oBwl//rTTsJ8enoVWsjDa/wr/mAmd2He7m+v5AtZe67 K+9kpd785IwKA== Date: Fri, 27 Jun 2025 13:20:11 +0200 From: Danilo Krummrich To: Vitaly Wool Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Uladzislau Rezki , Alice Ryhl , rust-for-linux@vger.kernel.org Subject: Re: [PATCH v5 3/4] rust: add support for NUMA ids in allocations Message-ID: References: <20250627092901.356909-1-vitaly.wool@konsulko.se> <20250627093858.413855-1-vitaly.wool@konsulko.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250627093858.413855-1-vitaly.wool@konsulko.se> X-Rspam-User: X-Stat-Signature: zrk1qbj4xrntj4bkmn8ppip8xrstkc49 X-Rspamd-Queue-Id: D8B17A0003 X-Rspamd-Server: rspam08 X-HE-Tag: 1751023216-419849 X-HE-Meta: U2FsdGVkX18aC701WXaR+nZA0DUjBONoBOo6QtFTHiA/ssRwj7G9/Tngf/lVCbHAt2FPeEFP1yE7js5P0ZA3sYy7wTfUKZSMWWfuBKLiwUif+NkZGdYZVzdm0ResNoLkImCLV6+/pS4TE6qZLxVx5zhKDoFUm9UqGA+mmse4M91dNQRuOOzkhoRKyXQc41zQa8jOhuOlcXPn5xMpuAQnGCEjtxoIMorBMC9C3xjEO4Q5cLL/RPntX7n5STyRUxtazuKxvLDAiXF1Bok9QtxGqVpx40HvdZIIpYUa5Hvs2/+teJAj8ZVgj5wjnyIQoUYaj6ERNmgKxsJCiKT6fHXhB8TpgXW30dYKZRbViKrMShwKTqDwPBOCI8OVEYMEjCBYnGHJndraMVtpAHFJN5iYrOmkIn4r/0XP8s50VUtbxmezMm2Ls+77vd5d4CteilTXhCVrKv5KXM/W+35PkZa/dskXmOlLTIrJvCFs2iXbYxC1kLm8sC4TgQ4CYB9FtpaF58pttw827koxK4UJ4ZzIuvuW/o2Y3+sdfzaMq3kYj/trjpmxF5ZL6diYOSbNgoKnQsWx58KcKgDspf9pEw+kEMsgTawyw836S3tj9/hOe3sd2nK64gF+Srx8AxY4DJjiHtQTSd+Me4XlT9LGSI1EKoMpRK3PMiuyzbJHVkx23/9KeQ66McEFZiyQMP/P9YG6/IK88Fa0vrBs+oClFqq3RtOOUpTN8L2mHqPTsFGwOEXjqfrxWmyNRuJkqP4dLHsRoPRGCnhxrIbnqOtHndqQTaboOnDuQzOuNBjQ9ItY7EeKqR7DyuJU2LpBnLFVPHbSv71HyF64GEHj7ZgrcfiD7s5WKkfxedFwU767smcCJoOBaz0M4UAnAbQd3yat2VSc7GCduy5Gfd0SJNu5Z0r9C+dsoL5hs8/7IMTR3emwMnUV0nZpzrDC47qwUw+yAUPOzhAZ90DOqGqU29gu8n0 FSSX5k81 q2voHfOtj5BLYAG76wlWwe/s68koODkdCf5sxrmpUDCEhV8WP63QOkJ0okCpWYD0dPeiPXEPA19zaPx5ffFHOvxyImAAJ8LtO1q/DtwL9PcysNcSemFElTF3TUjnF1M6xJHCO+uud3HrQFv7Wn5eycYq/tiPGE/LtRNf2PoytQZbzjXBZ9O/VtGGyZeuQMs3Eh8/8MzcidHXn+0gfW+nYFR2MphgcxZrgN7oVFx9v27sm0FP0qVDDgRysZHQj7j0XloML9nCDGxbqgKDxCHtumKsK1qLP3ZgY7zXsu1wjNAoL7eg= 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 Fri, Jun 27, 2025 at 11:38:58AM +0200, Vitaly Wool wrote: > + /// Allocate memory based on `layout`, `flags` and `nid`. The semantical meanting of layout and flags is rather obvious due to its type. We should probably introduce a new type NumaNode with a constant for NUMA_NODE_NONE. > + /// > + /// On success, returns a buffer represented as `NonNull<[u8]>` that satisfies the layout > + /// constraints (i.e. minimum size and alignment as specified by `layout`). > + /// > + /// This function is equivalent to `realloc` when called with `None`. > + /// > + /// # Guarantees > + /// > + /// When the return value is `Ok(ptr)`, then `ptr` is > + /// - valid for reads and writes for `layout.size()` bytes, until it is passed to > + /// [`Allocator::free`] or [`Allocator::realloc`], > + /// - aligned to `layout.align()`, > + /// > + /// Additionally, `Flags` are honored as documented in > + /// . > + fn alloc_node(layout: Layout, flags: Flags, nid: Option) > + -> Result, AllocError> { > + // SAFETY: Passing `None` to `realloc` is valid by its safety requirements and asks for a > + // new memory allocation. > + unsafe { Self::realloc(None, layout, Layout::new::<()>(), flags, nid) } > } > > /// Re-allocate an existing memory allocation to satisfy the requested `layout`. > @@ -196,6 +219,7 @@ unsafe fn realloc( > layout: Layout, > old_layout: Layout, > flags: Flags, > + nid: Option, > ) -> Result, AllocError>; Please rename to realloc_node() and expand the documentation explaining what happens for invalid nid numbers and what happens if nid changes throughout invocations. Also, please introduce realloc() which calls realloc_node() with NUMA_NODE_NONE. > > /// Free an existing memory allocation. > @@ -211,7 +235,7 @@ unsafe fn free(ptr: NonNull, layout: Layout) { > // SAFETY: The caller guarantees that `ptr` points at a valid allocation created by this > // allocator. We are passing a `Layout` with the smallest possible alignment, so it is > // smaller than or equal to the alignment previously used with this allocation. > - let _ = unsafe { Self::realloc(Some(ptr), Layout::new::<()>(), layout, Flags(0)) }; > + let _ = unsafe { Self::realloc(Some(ptr), Layout::new::<()>(), layout, Flags(0), None) }; > } > } > > diff --git a/rust/kernel/alloc/allocator.rs b/rust/kernel/alloc/allocator.rs > index aa2dfa9dca4c..4f0fe2b67593 100644 > --- a/rust/kernel/alloc/allocator.rs > +++ b/rust/kernel/alloc/allocator.rs > @@ -58,18 +58,20 @@ fn aligned_size(new_layout: Layout) -> usize { > /// > /// One of the following: `krealloc`, `vrealloc`, `kvrealloc`. > struct ReallocFunc( > - unsafe extern "C" fn(*const crate::ffi::c_void, usize, u32) -> *mut crate::ffi::c_void, > + unsafe extern "C" fn(*const crate::ffi::c_void, usize, crate::ffi::c_ulong, u32, > + crate::ffi::c_int > + ) -> *mut crate::ffi::c_void, > ); > > impl ReallocFunc { > - // INVARIANT: `krealloc` satisfies the type invariants. > - const KREALLOC: Self = Self(bindings::krealloc); > + // INVARIANT: `krealloc_node` satisfies the type invariants. > + const KREALLOC_NODE: Self = Self(bindings::krealloc_node); > > - // INVARIANT: `vrealloc` satisfies the type invariants. > - const VREALLOC: Self = Self(bindings::vrealloc); > + // INVARIANT: `vrealloc_node` satisfies the type invariants. > + const VREALLOC_NODE: Self = Self(bindings::vrealloc_node); > > - // INVARIANT: `kvrealloc` satisfies the type invariants. > - const KVREALLOC: Self = Self(bindings::kvrealloc); > + // INVARIANT: `kvrealloc_node` satisfies the type invariants. > + const KVREALLOC_NODE: Self = Self(bindings::kvrealloc_node); I think those constants can remain to be named just KREALLOC, etc.