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 2EE8BC83F1A for ; Thu, 10 Jul 2025 06:21:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C71F76B00A0; Thu, 10 Jul 2025 02:21:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C4A076B00A6; Thu, 10 Jul 2025 02:21:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5F3D8D0001; Thu, 10 Jul 2025 02:21:33 -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 A31336B00A0 for ; Thu, 10 Jul 2025 02:21:33 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 71DB7160476 for ; Thu, 10 Jul 2025 06:21:33 +0000 (UTC) X-FDA: 83647358466.02.5EDDB18 Received: from mailrelay-egress16.pub.mailoutpod3-cph3.one.com (mailrelay-egress16.pub.mailoutpod3-cph3.one.com [46.30.212.3]) by imf14.hostedemail.com (Postfix) with ESMTP id 72DD5100005 for ; Thu, 10 Jul 2025 06:21:31 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=txc3DVqO; dkim=pass header.d=konsulko.se header.s=ed1 header.b=5kgLgXZA ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752128491; a=rsa-sha256; cv=none; b=pvUE5Tw8U4mUcO12iL77CqeCCOtWSOw0Boxzv0vLouXTScn0jYLcBuL58KF3nCVBquJ/Jc 9tNxIp4GdAlDN6kvCsN+BipflQNAZ+XLax9wGhoh2thl8e/tr2JTn8deisj56ZDKz2YYwU cQGcZ7xYuFXgjKzyMFRaomWI6I+WOLc= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=txc3DVqO; dkim=pass header.d=konsulko.se header.s=ed1 header.b=5kgLgXZA; dmarc=none; spf=none (imf14.hostedemail.com: domain of vitaly.wool@konsulko.se has no SPF policy when checking 46.30.212.3) smtp.mailfrom=vitaly.wool@konsulko.se ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752128491; 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=YUiiGhRYEVBjI0HWIqFCgU1I2UaAdWFwjjw9E0peZRU=; b=P9iqrd8/W1rf2uVlYHXEEaMbaQ7n2b1sO/EIfONGWYYnKYiEXHUHRWmKEMN2rnzoJCCEUS aSR0aueE2IERhE6KRmEoyiwFj4vnJv+/9DlkAI2MwK2feLCfZF4kspmSAdDtNGQT4TztWg YXDuqihdwdnZN050EPIDckdh6E7TyE0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1752128490; x=1752733290; d=konsulko.se; s=rsa1; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:from; bh=YUiiGhRYEVBjI0HWIqFCgU1I2UaAdWFwjjw9E0peZRU=; b=txc3DVqOL9z6m1CU8fSyyl7BVst8mxmHC8v36QLOU/OdJLQZ5uZqxlcSfH2IxepoQVoByQs/ehMWF 9t8C+kuS0lkz/qmhOYSkw5w+uPucY/8De9c+GZIxIKxMB6Iy5HtkM4kaTOKl3tpOfN5NLOzls43sC5 3UoNR+OsaVovGKPlp840gypm2+mIERqAbVhq6UeGdtKeUsja9yJLQ3Sp6jPnNpaup8tMthh21pI1pH UJfFKh9a6CWsArWSU14Cu/iNeJGQNxQBJpoVARYS3G+qC/z5jRi1ihivouWVX8NOhD/CbsbCZ/I41+ MYCWQWZOyLQ3PNi0hier+5pWvCDhAAw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1752128490; x=1752733290; d=konsulko.se; s=ed1; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type: message-id:from:from; bh=YUiiGhRYEVBjI0HWIqFCgU1I2UaAdWFwjjw9E0peZRU=; b=5kgLgXZAPI2z3qbUc12ABvan/WAeE0kx49WvgchhSW+BDnWo5/MnHPFgG5gf+rPGBytNE1ZCB3SqC MaCzYx4Aw== X-HalOne-ID: 1ccc5b64-5d56-11f0-9439-c9fa7b04d629 Received: from smtpclient.apple (c188-150-224-8.bredband.tele2.se [188.150.224.8]) by mailrelay1.pub.mailoutpod3-cph3.one.com (Halon) with ESMTPSA id 1ccc5b64-5d56-11f0-9439-c9fa7b04d629; Thu, 10 Jul 2025 06:21:29 +0000 (UTC) From: Vitaly Wool Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E902E7BC-0275-4F1E-81C9-DD11EC5F6F41" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\)) Subject: Re: [PATCH v12 1/4] mm/vmalloc: allow to set node and align in vrealloc Date: Thu, 10 Jul 2025 08:21:19 +0200 In-Reply-To: Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Uladzislau Rezki , Danilo Krummrich , Alice Ryhl , Vlastimil Babka , rust-for-linux@vger.kernel.org, Lorenzo Stoakes , Kent Overstreet , linux-bcachefs@vger.kernel.org, bpf@vger.kernel.org, Herbert Xu , Jann Horn , Pedro Falcato To: "Liam R. Howlett" References: <20250709172345.1031907-1-vitaly.wool@konsulko.se> <20250709172416.1031970-1-vitaly.wool@konsulko.se> X-Mailer: Apple Mail (2.3826.200.121) X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 72DD5100005 X-Stat-Signature: yjk61p8y7dx11yiycgbweuobqn3dkjns X-HE-Tag: 1752128491-840963 X-HE-Meta: U2FsdGVkX18fHE/j0SUsuSZRHIuyqfoeLPZHvU8v6gaZdvPNk+5GuJ9jk7svl3xHb5uHIAJs6lCSY1IdUYLRn9TA03++PGS2t917Sv7KqtkEMNGuK1UBowLSAdGifkfBTJ6CTpPCpVIRZRDeiywSyDGK9/qy21jP7TW6ujKXp52IlPU6PFsenY4ySi1AWRSUY+8BbBPDbRe+GVaBdD6bXI0/KhzkrRyHowJzSoAgqqbKCobSso7pUITNUc9nlBNIrCBP9iSLqFk4CjNYJojPakhBHA+ScCVnEPtNT33cS7nwKVohSbVm0xBEdZAmX5dgYtraqeHIq6XTSrLQ4TundxofXqYeMDZjbC4dvmOAXhChzpp6ScEhaYKUMbQ4e1Kysk0RiFLi0UdypX2w7okfScx+fQYEFj1N4W6/aLHEw4UVOnUrQJNjs5gNVprlpWuK/lbWDPKiWbUdw2rrUaG2x5k9A/mZdWjPddZ62LPCaEZreGrs/mZQCPygtOYSUSX/gQx0xpPt+Dwif/mu7gNk0UwNiH/HH07cotgjbD340ITVWq3Aw9Y3JvqU6Kh4S4ofHWdsjoNyUFuQgTI0MBNPbHr2slc/Txnwu33WH7lHjdUcbBAL65L9otNjXNIIuqARVJAvCILzD0vcPnwKsO5gkpVcN21mNr2N28syu0Lb2F9LW7bdhJXdfscnnrd8gPIewtXnFlma/M4lLy8dFcYuLK7Re5vQO0huwU3ef6gw7ngzHi7qIPWfZhenheodFfczxoIDxsQKcQmxzCHWLG44GpeQX7vhz3uudiQAHQSQeUGGF0ozDsq9Fh97iCHCRcBTS3PCbV0BHZQAkUTISUeDLuKRXc/+coSSGrnx/+7MnDSKkTCDzOiXe/aPChIX7DoUB+zUqwHS8GLce1QFB0mDV3P5lqhrIB0LSJbaeSE6qUuODORSHHo4vwVT8TIoroP4iLEFqSNEdBRTjsDJlvt +udz8Lw0 lvNSQouFSYUlimlDWHH7awoi8JvHcmPSyE33ourh4aoTC6GfO3gT32RLup4DCB7y5uO2VdNrn3E98hEm6C9++B8I8+XjgE+pR5fghWt8AbfVmxQXkfkFebkMKKeT3q4IZAeT5oqWFQiy0+liodxPuhXSTcK4/kHenpsbcKNHx1Dz5EgyTZvdyBRMDVQJU4JErbMOhzVlPe6s1gJRVWI3E408vdjJNFPIhJtkQFkgMGI0O46ZksZZMDZvuA4NQljwZn4EnvUyYWraTj5/XegazYFqg6JCT2DRRckUpFjQpIM7DY4AvHKzNhrJKVv13XNkwXAPu/4iB9zpba4lqEQNzU6896819N7OFJBErlyuARCu51N0= 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: --Apple-Mail=_E902E7BC-0275-4F1E-81C9-DD11EC5F6F41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 9, 2025, at 9:01=E2=80=AFPM, Liam R. Howlett = wrote: >=20 > * Vitaly Wool > [250709 13:24]: >> Reimplement vrealloc() to be able to set node and alignment should >> a user need to do so. Rename the function to vrealloc_node_align() >> to better match what it actually does now and introduce macros for >> vrealloc() and friends for backward compatibility. >>=20 >> With that change we also provide the ability for the Rust part of >> the kernel to set node and alignment in its allocations. >>=20 >> Signed-off-by: Vitaly Wool >> Reviewed-by: Uladzislau Rezki (Sony) >> Reviewed-by: Vlastimil Babka >> --- >> include/linux/vmalloc.h | 12 +++++++++--- >> mm/nommu.c | 3 ++- >> mm/vmalloc.c | 31 ++++++++++++++++++++++++++----- >> 3 files changed, 37 insertions(+), 9 deletions(-) >>=20 > ... >=20 >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >> index 6dbcdceecae1..03dd06097b25 100644 >> --- a/mm/vmalloc.c >> +++ b/mm/vmalloc.c >> @@ -4089,19 +4089,31 @@ void *vzalloc_node_noprof(unsigned long size, = int node) >> EXPORT_SYMBOL(vzalloc_node_noprof); >>=20 >> /** >> - * vrealloc - reallocate virtually contiguous memory; contents = remain unchanged >> + * vrealloc_node_align_noprof - reallocate virtually contiguous = memory; contents >> + * remain unchanged >> * @p: object to reallocate memory for >> * @size: the size to reallocate >> + * @align: requested alignment >> * @flags: the flags for the page level allocator >> + * @nid: node number of the target node >> + * >> + * If @p is %NULL, vrealloc_XXX() behaves exactly like vmalloc(). If = @size is >> + * 0 and @p is not a %NULL pointer, the object pointed to is freed. >> * >> - * If @p is %NULL, vrealloc() behaves exactly like vmalloc(). If = @size is 0 and >> - * @p is not a %NULL pointer, the object pointed to is freed. >> + * if @nid is not NUMA_NO_NODE, this function will try to allocate = memory on >> + * the given node. If reallocation is not necessary (e. g. the new = size is less >> + * than the current allocated size), the current allocation will be = preserved >> + * unless __GFP_THISNODE is set. In the latter case a new allocation = on the >> + * requested node will be attempted. >=20 > I am having a very hard time understanding what you mean here. What = is > the latter case? >=20 > If @nis is !NUMA_NO_NODE, the allocation will be attempted on the = given > node. Then things sort of get confusing. What is the latter case? The latter case is __GFP_THISNODE present in flags. That=E2=80=99s the = latest if-clause in this paragraph. >=20 >> * >> * If __GFP_ZERO logic is requested, callers must ensure that, = starting with the >> * initial memory allocation, every subsequent call to this API for = the same >> * memory allocation is flagged with __GFP_ZERO. Otherwise, it is = possible that >> * __GFP_ZERO is not fully honored by this API. >> * >> + * If the requested alignment is bigger than the one the *existing* = allocation >> + * has, this function will fail. >> + * >=20 > It might be better to say something like: > Requesting an alignment that is bigger than the alignment of the > *existing* allocation will fail. >=20 The whole function description in fact consists of several if-clauses = (some of which are nested) so I am just following the pattern here. ~Vitaly= --Apple-Mail=_E902E7BC-0275-4F1E-81C9-DD11EC5F6F41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 9, 2025, at 9:01=E2=80=AFPM, Liam R. Howlett = <Liam.Howlett@oracle.com> wrote:

* Vitaly Wool <vitaly.wool@konsulko.se> = [250709 13:24]:
Reimplement vrealloc() to be able to set node = and alignment should
a user need to do so. Rename the function to = vrealloc_node_align()
to better match what it actually does now and = introduce macros for
vrealloc() and friends for backward = compatibility.

With that change we also provide the ability for = the Rust part of
the kernel to set node and alignment in its = allocations.

Signed-off-by: Vitaly Wool = <vitaly.wool@konsulko.se>
Reviewed-by: Uladzislau Rezki (Sony) = <urezki@gmail.com>
Reviewed-by: Vlastimil Babka = <vbabka@suse.cz>
---
include/linux/vmalloc.h | 12 = +++++++++---
mm/nommu.c =             &n= bsp;|  3 ++-
mm/vmalloc.c =            | 31 = ++++++++++++++++++++++++++-----
3 files changed, 37 insertions(+), 9 = deletions(-)

...

diff --git a/mm/vmalloc.c = b/mm/vmalloc.c
index 6dbcdceecae1..03dd06097b25 100644
--- = a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -4089,19 +4089,31 @@ void = *vzalloc_node_noprof(unsigned long size, int = node)
EXPORT_SYMBOL(vzalloc_node_noprof);

/**
- * vrealloc = - reallocate virtually contiguous memory; contents remain unchanged
+ = * vrealloc_node_align_noprof - reallocate virtually contiguous memory; = contents
+ * remain unchanged
 * @p: object to reallocate = memory for
 * @size: the size to reallocate
+ * @align: = requested alignment
 * @flags: the flags for the page level = allocator
+ * @nid: node number of the target node
+ *
+ * If = @p is %NULL, vrealloc_XXX() behaves exactly like vmalloc(). If @size = is
+ * 0 and @p is not a %NULL pointer, the object pointed to is = freed.
 *
- * If @p is %NULL, vrealloc() behaves exactly like = vmalloc(). If @size is 0 and
- * @p is not a %NULL pointer, the = object pointed to is freed.
+ * if @nid is not NUMA_NO_NODE, this = function will try to allocate memory on
+ * the given node. If = reallocation is not necessary (e. g. the new size is less
+ * than = the current allocated size), the current allocation will be = preserved
+ * unless __GFP_THISNODE is set. In the latter case a new = allocation on the
+ * requested node will be = attempted.

I am = having a very hard time understanding what you mean here.  What = is
the latter = case?

If @nis is = !NUMA_NO_NODE, the allocation will be attempted on the given
node.  Then things sort of get = confusing.  What is the latter case?

The latter = case is __GFP_THISNODE present in flags. That=E2=80=99s the latest = if-clause in this paragraph.

 *
 * If __GFP_ZERO logic is requested, callers must = ensure that, starting with the
 * initial memory allocation, = every subsequent call to this API for the same
 * memory = allocation is flagged with __GFP_ZERO. Otherwise, it is possible = that
 * __GFP_ZERO is not fully honored by this = API.
 *
+ * If the requested alignment is bigger than the one = the *existing* allocation
+ * has, this function will fail.
+ = *

It might be better to = say something like:
Requesting an alignment that is bigger than the alignment = of the
*existing* allocation = will fail.


The whole function description = in fact consists of several if-clauses (some of which are nested) so I = am just following the pattern = here.

~Vitaly
= --Apple-Mail=_E902E7BC-0275-4F1E-81C9-DD11EC5F6F41--