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 9FBA2C83F10 for ; Sat, 12 Jul 2025 12:44:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 07D898D0003; Sat, 12 Jul 2025 08:44:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0062B8D0001; Sat, 12 Jul 2025 08:44:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E10398D0003; Sat, 12 Jul 2025 08:44:07 -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 C58118D0001 for ; Sat, 12 Jul 2025 08:44:07 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0E37A1D3848 for ; Sat, 12 Jul 2025 12:44:07 +0000 (UTC) X-FDA: 83655580134.01.CC1ECD5 Received: from mailrelay-egress16.pub.mailoutpod3-cph3.one.com (mailrelay-egress16.pub.mailoutpod3-cph3.one.com [46.30.212.3]) by imf30.hostedemail.com (Postfix) with ESMTP id B173B80015 for ; Sat, 12 Jul 2025 12:44:04 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=021r4Foq; dkim=pass header.d=konsulko.se header.s=ed1 header.b=nzRAI9Bm ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752324245; 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=3hsAftBbWhEHVqUIKPhJJLEw9P2gRr/T0ErS4BPPLBI=; b=gNrE0/w0KNpxh9FLcjfeJJ9fubaHk8wOzuRuCx5pvdt/rJj8Nt2+/MVMAd8jrjh0Rc+JTZ eeIsYougYzgDJuqDUNbfHXm6wXw3TyFC5O06q2zeNcl/u2hAe1IyCmekmuwgq63QDHZiHJ RUkfs3fgrN6HLTIv5LZSd/iRkvlqChk= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=021r4Foq; dkim=pass header.d=konsulko.se header.s=ed1 header.b=nzRAI9Bm; spf=none (imf30.hostedemail.com: domain of vitaly.wool@konsulko.se has no SPF policy when checking 46.30.212.3) smtp.mailfrom=vitaly.wool@konsulko.se; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752324245; a=rsa-sha256; cv=none; b=cZkrh9a3PTrVgv7lvLsh6d2vBzecwffTj5DltkcOYkZ8F6VEujauakxqXxmqM2Pn2dE0H3 T74S1U1K8mtPKduXnhVfOLXrWgbpcpM6Blx6Z7+tFcr4NfIPbS+4aBFcgnp7gw/ekqvIcK JXYGHTkizn1tSp+HyC+3BqZIWS7KLac= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1752324242; x=1752929042; 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=3hsAftBbWhEHVqUIKPhJJLEw9P2gRr/T0ErS4BPPLBI=; b=021r4Foqi/XPzdzuHHaBc/y43I6LhWARnZteRrjDdXyLagsCMHjGqpuI0z1jKAHp/bsoyGB3ypbKl nRZa336xwNRGhc1O/+ebjgEb5SFzsgVNTxVRuqwUNo5xrWQ3rF91M5Xu+PRq6m6hqaSB9IbkQI9R7q h4rWmJryPbxsrf+tcuS0DGoIikZzfrlFAHx7EUe/KhuUzs9FR7bLEBUp9E2Oi2gVyjgWRHLL49d/D6 3J/R0fJE9LZCSRP4+DnwogDq+z9/y5TOVcE7+AwLNfcWu5u0QRWFMGf0McGwZgCqwim3+mdhkR7RH6 Bo7/NgB0zJfAHhV4kYsCl9lrg/DrKqQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1752324242; x=1752929042; 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=3hsAftBbWhEHVqUIKPhJJLEw9P2gRr/T0ErS4BPPLBI=; b=nzRAI9Bmd8f+g3EqfvU7tY76SJchTfBnMo5Yh+77Sb5A6fJ1GUbyHxw6yupAh65rwqwMZ+0PVUXwO zFFy29sDA== X-HalOne-ID: e2b9d497-5f1d-11f0-b78d-85eb291bc831 Received: from smtpclient.apple (c188-150-224-8.bredband.tele2.se [188.150.224.8]) by mailrelay5.pub.mailoutpod2-cph3.one.com (Halon) with ESMTPSA id e2b9d497-5f1d-11f0-b78d-85eb291bc831; Sat, 12 Jul 2025 12:44:01 +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 v12 2/4] mm/slub: allow to set node and align in k[v]realloc From: Vitaly Wool In-Reply-To: <5bc89531-ab09-4690-aae4-a44f9ddb4a68@suse.cz> Date: Sat, 12 Jul 2025 14:43:51 +0200 Cc: Harry Yoo , linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Uladzislau Rezki , Danilo Krummrich , Alice Ryhl , rust-for-linux@vger.kernel.org, Lorenzo Stoakes , "Liam R . Howlett" , Kent Overstreet , linux-bcachefs@vger.kernel.org, bpf@vger.kernel.org, Herbert Xu , Jann Horn , Pedro Falcato Content-Transfer-Encoding: quoted-printable Message-Id: <3AD3F7B5-679F-4DC8-968F-9FE991B56A5C@konsulko.se> References: <20250709172345.1031907-1-vitaly.wool@konsulko.se> <20250709172441.1032006-1-vitaly.wool@konsulko.se> <5bc89531-ab09-4690-aae4-a44f9ddb4a68@suse.cz> To: Vlastimil Babka X-Mailer: Apple Mail (2.3826.200.121) X-Rspam-User: X-Rspamd-Queue-Id: B173B80015 X-Rspamd-Server: rspam06 X-Stat-Signature: 3w5ycpcboig9wpeemcypdmytcreudjj4 X-HE-Tag: 1752324244-228440 X-HE-Meta: U2FsdGVkX184fwEJSnXmclwrCYOcxTk5jRh587jPkSfK4DbXmwZ41+yI2AujqOV7jX/PI51tF9Ey1bgxwBhGWLVSnNFWaTn6t7BPQxiuZXu//ocm6II7SIdt34dcTcjq9M6dNgCLi3bvSL/SRuHC+tRoI+4dFYjwA87qmlWYt4OPBNGdpjF1jSLO/C/ZNVVmRExUIIwxWpPvuvb2/rqCT73tpJaO24xfflU/12udFIPZbWUO68AYADpKlTXOqV59JG7yHrSBJHdbuJ125aqczzcZOdNR0XSPKDba8UJNytAeJY4mkBnkrq9vSRjX5kEYMhw5+HDhyCUn8g2LwBkwbYY9TI13qetKWFM1Mg6SrtM8/dniOM3uUbDJmkuMfVlfdwJoJEi8pJzEbhiIdCcseFwRfSYF2GQ6bCc2CX8NGSYHrwKMR9OSP7jGNGuk/v5WeRqBBBj53tGRuvdC7xeEBJpTFkLeObpoVCFQrurbfdkZooej2FBdyuyII1x7QJ8NeE+gmO7aQtITmaiLMag9/bSm5sNHkCD+sWuOQ8XoSrYFdw+YmRQP6yDV+suYn4biP7dki1swLrewP8nW3rjb+yGOF0nz0u+vUxNxtKQx6AYyUpQsXJL2Zj/Jpwjb42L4HxhZIrr9Z25XgE4UPU8nsHKQ7zeESt3FVyjBQBYm2q4f3fNNpsnuOXJVSxtZZ0Bcst+qwHbHlWxDK00fGFh9ODpV6DosQBsypk1KWU4yC2v/6DFi9ABDznl8Im4B7sqZmAHVbStMPLaa4HHykja48gCXx63G8LVI3bkpCbLw+1S4R8roSeQZYQNj+LAjjJ0YWUW7P1P/4QBZUsOlzH3aCPuWk8bzySa/ych+ATw3fbpv5/e81wgE+LmpyKv2CXl5CH5Tygi0Ko/6RPqluFH+Kd1WWW4Moqepf7t6ZX6AG3ORs9Wo+m5eMsEmAiL+wQYZn1YKMnN9DTtMPjaHVjl hLmwx0nh vuCf61Xb/3GJ/fRyp5hjUSBa4y6w7xm0YXERwiOd7myLaeFkaJzAPgnpAyhPfPOPn0sAualpM3mH518y8uQcM4Vm3Va9i5AoYi8xUjqK8o9jAMAP7lAvI28I4/6ckotXOZdFPULEkmblvqk2yzj5jd/3TeyPwCyLOPVT67jxWekRlMxt65bLUu/F6CJ/RCf6ZyZ5X 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 Jul 11, 2025, at 5:43=E2=80=AFPM, Vlastimil Babka = wrote: >=20 > On 7/11/25 10:58, Harry Yoo wrote: >> On Wed, Jul 09, 2025 at 07:24:41PM +0200, Vitaly Wool wrote: >>> Reimplement k[v]realloc_node() to be able to set node and >>> alignment should a user need to do so. In order to do that while >>> retaining the maximal backward compatibility, add >>> k[v]realloc_node_align() functions and redefine the rest of API >>> using these new ones. >>>=20 >>> While doing that, we also keep the number of _noprof variants to a >>> minimum, which implies some changes to the existing users of older >>> _noprof functions, that basically being bcachefs. >>>=20 >>> With that change we also provide the ability for the Rust part of >>> the kernel to set node and alignment in its K[v]xxx >>> [re]allocations. >>>=20 >>> Signed-off-by: Vitaly Wool >>> --- >>> fs/bcachefs/darray.c | 2 +- >>> fs/bcachefs/util.h | 2 +- >>> include/linux/bpfptr.h | 2 +- >>> include/linux/slab.h | 38 +++++++++++++++---------- >>> lib/rhashtable.c | 4 +-- >>> mm/slub.c | 64 = +++++++++++++++++++++++++++++------------- >>> 6 files changed, 72 insertions(+), 40 deletions(-) >>=20 >>> diff --git a/mm/slub.c b/mm/slub.c >>> index c4b64821e680..6fad4cdea6c4 100644 >>> --- a/mm/slub.c >>> +++ b/mm/slub.c >>> @@ -4845,7 +4845,7 @@ void kfree(const void *object) >>> EXPORT_SYMBOL(kfree); >>>=20 >>> static __always_inline __realloc_size(2) void * >>> -__do_krealloc(const void *p, size_t new_size, gfp_t flags) >>> +__do_krealloc(const void *p, size_t new_size, unsigned long align, = gfp_t flags, int nid) >>> { >>> void *ret; >>> size_t ks =3D 0; >>> @@ -4859,6 +4859,20 @@ __do_krealloc(const void *p, size_t new_size, = gfp_t flags) >>> if (!kasan_check_byte(p)) >>> return NULL; >>>=20 >>> + /* refuse to proceed if alignment is bigger than what kmalloc() = provides */ >>> + if (!IS_ALIGNED((unsigned long)p, align) || new_size < align) >>> + return NULL; >>=20 >> Hmm but what happens if `p` is aligned to `align`, but the new object = is not? >>=20 >> For example, what will happen if we allocate object with size=3D64, = align=3D64 >> and then do krealloc with size=3D96, align=3D64... >>=20 >> Or am I missing something? >=20 > Good point. We extended the alignment guarantees in commit = ad59baa31695 > ("slab, rust: extend kmalloc() alignment guarantees to remove Rust = padding") > for rust in a way that size 96 gives you alignment of 32. It assumes = that > rust side will ask for alignments that are power-of-two and sizes that = are > multiples of alignment. I think if that assumption is still honored = than > this will keep working, but the check added above (is it just a sanity = check > or something the rust side relies on?) doesn't seem correct? >=20 It is a sanity check and it should have looked like this: if (!IS_ALIGNED((unsigned long)p, align) && new_size <=3D ks) return NULL; and the reasoning for this is the following: if we don=E2=80=99t intend = to reallocate (new size is not bigger than the original size), but the = user requests a larger alignment, it=E2=80=99s a miss. Does that sound = reasonable? ~Vitaly