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 8406BC7EE30 for ; Thu, 26 Jun 2025 16:29:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24B726B009C; Thu, 26 Jun 2025 12:29:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FB966B00A1; Thu, 26 Jun 2025 12:29:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 111916B00AF; Thu, 26 Jun 2025 12:29:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 000726B009C for ; Thu, 26 Jun 2025 12:29:39 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7C9CDB8160 for ; Thu, 26 Jun 2025 16:29:39 +0000 (UTC) X-FDA: 83598087678.17.471FB60 Received: from mailrelay2-3.pub.mailoutpod3-cph3.one.com (mailrelay2-3.pub.mailoutpod3-cph3.one.com [46.30.212.1]) by imf29.hostedemail.com (Postfix) with ESMTP id 268AF12000A for ; Thu, 26 Jun 2025 16:29:36 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=XfHWg0fJ; dkim=pass header.d=konsulko.se header.s=ed1 header.b=cKofyBaP ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750955377; 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=Pe7xeslr3EnaI4eQ4G3Fal7OrGAZHQXi7GxA/Z6tTtk=; b=gBuOVRs/PIIgaBOHRDHGedSAD533b9MR1FH6LwBVYUB9uoD3MvPe8xoGW5pY8wGz4+2alg +dgyb71W1RuOsCUDmGYNILtXZWybEOoj/QpSy7FGq+GsT1mj1B8jX0WQrCoZSFPJdR2dAt LW4yulpkcMXXEA2aGUgoE/+ZiwQy6vU= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=XfHWg0fJ; dkim=pass header.d=konsulko.se header.s=ed1 header.b=cKofyBaP; spf=none (imf29.hostedemail.com: domain of vitaly.wool@konsulko.se has no SPF policy when checking 46.30.212.1) smtp.mailfrom=vitaly.wool@konsulko.se; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750955377; a=rsa-sha256; cv=none; b=rb7IGjc7KOVaxu1EYdYhkce8Bre0vRfaotafi+rLGLpodvB+KeGXXWe6wup3SwMIVnPvZw 28e0y9Zt//cQnGytGCL13W4v4WqfiE7ok56NERq2uTzpsoTO/mlEhl+k8u2mhSSjxVWJ3G YNKcvCeDYNZf4V1fkPy3KDZdOF00VFM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1750955375; x=1751560175; d=konsulko.se; s=rsa1; h=to:references:message-id:content-transfer-encoding:cc:date:in-reply-to:from: subject:mime-version:content-type:from; bh=Pe7xeslr3EnaI4eQ4G3Fal7OrGAZHQXi7GxA/Z6tTtk=; b=XfHWg0fJ2o4Qj61LVARguZS8GfMl6j4JhwJrJrh6JvTe4McQ+XVbFl0NEhyaFU3O3iSzOI9nhOTS2 d+ZiJ06ASlW1Wfa5su7ojDGVKLzdl+1RUaek0nN7uklAs3mKvdGfhJRmEKjw+XS5y7yo8n28+UHWD9 HQjj0Pu+9g8+wVMX/l9SdkDhGCfJWO4ovD1ej9Jnoar+NRG3OsITcIDLHNRijZJbRqaROCZ4+LSUdn gSULaR3ic+5BdCKTJ+gsiNKbrI8kRrKs2kBArttjXwLWU2JjP/q/LeeOzRBmaZuh5u+U8x6xGix4Rk qa8pcNLyl3M1eU3zvHJ1IYje6W57zpQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1750955375; x=1751560175; d=konsulko.se; s=ed1; h=to:references:message-id:content-transfer-encoding:cc:date:in-reply-to:from: subject:mime-version:content-type:from; bh=Pe7xeslr3EnaI4eQ4G3Fal7OrGAZHQXi7GxA/Z6tTtk=; b=cKofyBaPtXskP+rf2X2G0lhLuOIxo8k+IKnJCrRnZz3GEwGrqC6csA0L4RG8DslhJULU8M8M8q1lu RrGRTz/Ag== X-HalOne-ID: be6172b6-52aa-11f0-9c3a-b37c246f863f Received: from smtpclient.apple (c188-150-224-8.bredband.tele2.se [188.150.224.8]) by mailrelay2.pub.mailoutpod3-cph3.one.com (Halon) with ESMTPSA id be6172b6-52aa-11f0-9c3a-b37c246f863f; Thu, 26 Jun 2025 16:29:34 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\)) Subject: Re: [PATCH v4 3/4] rust: support large alignments in allocations From: Vitaly Wool In-Reply-To: Date: Thu, 26 Jun 2025 18:29:24 +0200 Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Uladzislau Rezki , Alice Ryhl , rust-for-linux@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <72365C10-D984-4BC5-A081-B058C1619D06@konsulko.se> References: <20250626083516.3596197-1-vitaly.wool@konsulko.se> <20250626083642.3596388-1-vitaly.wool@konsulko.se> To: Danilo Krummrich X-Mailer: Apple Mail (2.3826.200.121) X-Rspamd-Queue-Id: 268AF12000A X-Stat-Signature: ec6xfuz7teut5zxix3hyuabghn9pk5p1 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1750955376-854494 X-HE-Meta: U2FsdGVkX1/ZB4pkRUP69AsgP2gGmcly6h98UigU3ww/0IpE2NHov2EDTxJXRh+KER8NK+Oi7beAqZ5vMgWCShIwv6YXSBXy8haTx5VzHKCoro2otvUbbaw2uT3s/I2LUkWnt/3sI22IvMzcvGZ1Mofnlnlx4c5v58t5fT78HqiYV3PcxW0/WdjDB29RHRQKqTA9dSmW4JtVy0CntSTk/6wn7o/coAXqzVB1pDEESA7mnz8Gf1FgVr7VJkBnLk+McL2z9S4l2ehzgwY5SiXVZPg2NhlZp1lcqItbBHi48i/FjFG8P1zZH75cfX7O6kQ9uR4QuYEQkq8VCRCZ0Z6t3VnCJwPmA6HWtDx7H1Q6ibDj57TbmI8h97XCrMx/d+E5b4JaAJLtwx9Snr4yTJd31GU5Au5GTnZOJKGh8F2wwGKt/uTtIHJiXvurOb3v60lqrXUqLcIE0SqnzpadBJ200nh5XcUlOGzf7dk4kxTR3MbLvCTPrsw4Hm4jO8wQwWObcWUP0XRqRULKNNimm3IwwH6LV7cT/FPuSo2E8elSwJezs+5z/WvWvXruPIan2FwxFRG7Q8QdNosa/U/mWdR58fOz4FsPssYXtCrSWdsX/YJE9ksVKACYpXsOmuL1UKBHg6Q54Iuiri1sQTpU9tIXxVc+SingjdOGjkRAMi65Iej7gaiTyMi/fYrXNVe8yJTdbmK1LNqU/pGWWagEHqmKHOTclkMA/AJ8bhRhh0qi7MPFXTD2fmxpR7aySNNrXRnczRFZxYVszsm9cZ+hpBTns8M7dtuuVnDJ5xjxXuDt3uQAGGmvIlLeqaEIRwhDNfy+3T3W7g2m57cp/mAVuQia8yf4UiNFIWjwwKiPLV/rX69eU2OvRkYq9HROpYduRIKoXwCdtJgUl69yF+x6biPIrF+6MHoDqh0yOCPCYfbYFxZ5aBjSO93XZr/M0yxyZBBPFB34pirbeQCB4wtwVt/ SKByxZBR 4MSG0c0o/cVXVw6iGPldiaDHMn0uUzNAMBphsC+EKDi00dz04NgVdBUA9sHime0ubf35iYUSn5YACipFh9vbQ63jHJbr3lGCFYmGPCNlaRWjnYxBY6+NvhOnjKOv5x6TbihS2aBRHRkdJf6lNywOL2ewu1CgCTPmf5x4ZKprj968ivA0NgXzfl5+2acpdcsXb4TzEZI1+qEyCr/87jvxRB2deL2/7QkPL0qsrgJGR4c063VEqlGqAydlTsA== 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 Jun 26, 2025, at 2:36=E2=80=AFPM, Danilo Krummrich = wrote: >=20 > On Thu, Jun 26, 2025 at 10:36:42AM +0200, Vitaly Wool wrote: >> void * __must_check __realloc_size(2) >> -rust_helper_krealloc(const void *objp, size_t new_size, gfp_t flags) >> +rust_helper_krealloc(const void *objp, size_t new_size, unsigned = long align, gfp_t flags) >> { >> return krealloc(objp, new_size, flags); >> } >>=20 >> void * __must_check __realloc_size(2) >> -rust_helper_kvrealloc(const void *p, size_t size, gfp_t flags) >> +rust_helper_kvrealloc(const void *p, size_t size, unsigned long = align, gfp_t flags) >> { >> return kvrealloc(p, size, flags); >> } >=20 > I think you forgot to add comments explaining why we have the = additional > discarded align argument. >=20 > Also please keep those helpers as they are. You can write an identical = inline > function in Rust that discards the align argument and calls = bindings::krealloc, > etc. >=20 > For instance: >=20 > unsafe extern "C" fn krealloc_align( > ptr: *const c_void, > size: usize, > _align: c_ulong > flags: u32, > ) -> *mut c_void { > bindings::krealloc(ptr, size, flags) > } >=20 Ugh. This is indeed a mistake from my side but I don=E2=80=99t quite = agree with your variant here too. The thing is that the new patchset has a patch #2 which adds = kvrealloc_node and realloc_node so this chunk IMO should have looked = like -rust_helper_kvrealloc(const void *p, size_t size, gfp_t flags) +rust_helper_kvrealloc(const void *p, size_t size, unsigned long align, = gfp_t flags) { - return kvrealloc(p, size, flags); + return kvrealloc_node(p, size, align, flags, NUMA_NO_NODE); } =E2=80=A6exactly like for vmalloc, see also my comment below. >> diff --git a/rust/helpers/vmalloc.c b/rust/helpers/vmalloc.c >> index 80d34501bbc0..4618c0b79283 100644 >> --- a/rust/helpers/vmalloc.c >> +++ b/rust/helpers/vmalloc.c >> @@ -3,7 +3,7 @@ >> #include >>=20 >> void * __must_check __realloc_size(2) >> -rust_helper_vrealloc(const void *p, size_t size, gfp_t flags) >> +rust_helper_vrealloc(const void *p, size_t size, unsigned long = align, gfp_t flags) >> { >> - return vrealloc(p, size, flags); >> + return vrealloc_node(p, size, align, flags, NUMA_NO_NODE); >> } >=20 > Same here, just make this a "real" helper for vrealloc_node() and = create a Rust > function vrealloc_align() like in the example above. Wait, why? What=E2=80=99s the use of vrealloc() if it doesn=E2=80=99t = provide the align functionality that we need? >=20 >> diff --git a/rust/kernel/alloc/allocator.rs = b/rust/kernel/alloc/allocator.rs >> index aa2dfa9dca4c..a0d78c497974 100644 >> --- a/rust/kernel/alloc/allocator.rs >> +++ b/rust/kernel/alloc/allocator.rs >> @@ -58,7 +58,7 @@ 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, usize, = u32) -> *mut crate::ffi::c_void, >=20 > Should be c_ulong instead of usize. >=20 Noted. >> ); >>=20 >> impl ReallocFunc { >> @@ -110,7 +110,7 @@ unsafe fn call( >> // - Those functions provide the guarantees of this function. >> let raw_ptr =3D unsafe { >> // If `size =3D=3D 0` and `ptr !=3D NULL` the memory = behind the pointer is freed. >> - self.0(ptr.cast(), size, flags.0).cast() >> + self.0(ptr.cast(), size, layout.align(), flags.0).cast() >> }; >>=20 >> let ptr =3D if size =3D=3D 0 { >> @@ -152,12 +152,6 @@ unsafe fn realloc( >> old_layout: Layout, >> flags: Flags, >> ) -> Result, AllocError> { >> - // TODO: Support alignments larger than PAGE_SIZE. >> - if layout.align() > bindings::PAGE_SIZE { >> - pr_warn!("Vmalloc does not support alignments larger = than PAGE_SIZE yet.\n"); >> - return Err(AllocError); >> - } >> - >> // SAFETY: If not `None`, `ptr` is guaranteed to point to = valid memory, which was previously >> // allocated with this `Allocator`. >> unsafe { ReallocFunc::VREALLOC.call(ptr, layout, old_layout, = flags) } >> @@ -176,12 +170,6 @@ unsafe fn realloc( >> old_layout: Layout, >> flags: Flags, >> ) -> Result, AllocError> { >> - // TODO: Support alignments larger than PAGE_SIZE. >> - if layout.align() > bindings::PAGE_SIZE { >> - pr_warn!("KVmalloc does not support alignments larger = than PAGE_SIZE yet.\n"); >> - return Err(AllocError); >> - } >=20 > Didn't you propose to use VREALLOC if layout.align() > = bindings::PAGE_SIZE? >=20 I did, and this is what happens on the C side now, please see the #2 = patch in series. I think it=E2=80=99s better this way because of uniformity but I don=E2=80= =99t have a strong opinion on this. >> // SAFETY: If not `None`, `ptr` is guaranteed to point to = valid memory, which was previously >> // allocated with this `Allocator`. >> unsafe { ReallocFunc::KVREALLOC.call(ptr, layout, old_layout, = flags) } >=20