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 3F75BC83F17 for ; Tue, 15 Jul 2025 07:03:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A66A56B0089; Tue, 15 Jul 2025 03:03:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A17646B008A; Tue, 15 Jul 2025 03:03:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 954176B0092; Tue, 15 Jul 2025 03:03:44 -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 85B1D6B0089 for ; Tue, 15 Jul 2025 03:03:44 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0AF341403ED for ; Tue, 15 Jul 2025 07:03:44 +0000 (UTC) X-FDA: 83665608768.13.CF36C4D Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf16.hostedemail.com (Postfix) with ESMTP id 17428180004 for ; Tue, 15 Jul 2025 07:03:41 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=drRX8Kfb; spf=pass (imf16.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752563022; 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=jt/6M57mZgMPhITvF8HdLS12vV1vFn0N4xhHPTTFoy0=; b=aMj1MJgKyLKeipejfwTK1Afxf8iAtADsXyDla2jcSk6GhDFaRNYW5B/J7nmG09dV7/Tylx hqd2n5kGrUxxXDFq7BVL43t0ZVf+5bkRIKXWeX7lkZ9+pbVPYdeMEPzO8vgR1N7MNgBbCJ DFIk770tIQx20IyYK4ROr7KhJcQljOU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752563022; a=rsa-sha256; cv=none; b=1Pk/0TjvFA9qXhDGeteJ/4/o6OT8TJ2P+XRBHJ+vEItbSxniWKE+55VClKgLHpRfK6vBVW KlPytVcfapSOba+926D3jM44oQqV+2vQORqNZKnjvzwQhh7tUt9bWofr0IN34gV/5+Y29s oZ0bK8aMKpL23nczbeekogMr4q3Fvl8= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=drRX8Kfb; spf=pass (imf16.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-451d6ade159so36393025e9.1 for ; Tue, 15 Jul 2025 00:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752563020; x=1753167820; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jt/6M57mZgMPhITvF8HdLS12vV1vFn0N4xhHPTTFoy0=; b=drRX8Kfbx5C2ySchZqqeeKZa4w+tfPPlI660THjengoCN7GY8cR5haTlasnsziFe0E wqfAPmdzvFOLM+FVEYjAMlMGf6MpjgzblUjF8UnqROsaLRzRyJOse4PKsV0UP1MyHmu2 Q0KFO2gsMEZQx4/oLoUF9quUf1vW6IuKl2JTN152TnQ8wNSHKdoWBxNTopMh3gBRgJID e1hyV1Ck7SfOO1Z32k/TECKTnMo3J6X5AzEBWjsAz0GOMJNqdTVtsuqKhio7kmh2MCk7 YIVaQeMRPWfpBUEvwDC8kRr8uvKp+PSJGi9AOjudbOrRLC423GWdOWUefOc7tgOLNvR+ v0VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752563020; x=1753167820; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jt/6M57mZgMPhITvF8HdLS12vV1vFn0N4xhHPTTFoy0=; b=RxwSC82q9u85GE3O8+zEhQLGUnUFx0PMV9mBsyzSRZ/s2fxXHbO3ZHCwh7LFjKgBdF O7LWT6Eg5/Q3vcvBYc+VxgI3vp6oa0h/3mDNGk0XGc+5bXOpGGxI/dfZPMxfBCFLtenS BNm/ErR6AEDXMAs2Dkv8zaFneXwRtYEAjRp3UtEPs0OjCMpLYvhMtmHq4IyQ6ysWvAJJ oySAzg4+NDzg9JkebE6F/oBQqeVtza2FqHDnHLFtRZv9L/6/KcOcxp/Sm/IsSjXtmPm2 BqA4CuWZ901hQIVNvtIvRfgUm6MzI6JQboOvQ+BO8AYAXA0sqSHgo1GVpvqt4AC66b8D AgQA== X-Forwarded-Encrypted: i=1; AJvYcCVTLypNPpUyTYofaaKpULCv4j3j0Fy/NEaL9Eh2mmSZzMzsO8cSW72vT7Qv9tKX3nZ6H04kfMtIUw==@kvack.org X-Gm-Message-State: AOJu0YzOJBLryDpexrq4AN4bAOcyD9Z/7Mb3BzrEPmq85OYR2YHl+sy1 EBtI8xNF5r6UAtTsiMQdhbdkt7HVRW4R7XA9bwUctdXWdZI2JneDMd8uBpOs/kuuAIcT8y9Gbho xcYZxVLp9kQuMgbIsbYD0FJKd7+7RlPKWo1iLCHiK X-Gm-Gg: ASbGnctip8xuug+Q0JFBzJbk5p1zQVyig/CWKO8idaQ8KarGFNmBCdEw9pUxASqDUAL FpraalDwumhcikeJnoAZB/Ousi6Qmt6GbUfiCrg+gERr0YG/weeAc7v5YpjZHoIte0rnOMTnmxx rG14fKT9EL/mLjtJq34RzcfXtAOdKW+OZOV3oeivaLZSt5+rUlzaxrNL/cTojpxHvSdBPp8YaJG 6oCluVP X-Google-Smtp-Source: AGHT+IE1/MY0RQcecLFoHvQZdO+7sZGnb0kcJHS9oa/ewG1ZdNmenXVcPC2k1yhTjRTUuDq69k9FOq7rxEcXnfgllNg= X-Received: by 2002:a05:6000:1a86:b0:3a4:eda1:6c39 with SMTP id ffacd0b85a97d-3b5f2dc216dmr10969220f8f.13.1752563020324; Tue, 15 Jul 2025 00:03:40 -0700 (PDT) MIME-Version: 1.0 References: <20250709172345.1031907-1-vitaly.wool@konsulko.se> <20250709172441.1032006-1-vitaly.wool@konsulko.se> <5bc89531-ab09-4690-aae4-a44f9ddb4a68@suse.cz> <3AD3F7B5-679F-4DC8-968F-9FE991B56A5C@konsulko.se> <1dedcee0-c5a2-47b3-ae13-315ad437ae1a@suse.cz> In-Reply-To: <1dedcee0-c5a2-47b3-ae13-315ad437ae1a@suse.cz> From: Alice Ryhl Date: Tue, 15 Jul 2025 09:03:27 +0200 X-Gm-Features: Ac12FXx5pgrLnvLVllVwWAxwc6ktT76M5E8OvULeGL7H3WltRDY_yqdMh5SmBiA Message-ID: Subject: Re: [PATCH v12 2/4] mm/slub: allow to set node and align in k[v]realloc To: Vlastimil Babka Cc: Vitaly Wool , Harry Yoo , linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Uladzislau Rezki , Danilo Krummrich , 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-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 17428180004 X-Rspam-User: X-Rspamd-Server: rspam09 X-Stat-Signature: kcum16ideor7ccy7tfbmhrgsp8rtdts6 X-HE-Tag: 1752563021-931521 X-HE-Meta: U2FsdGVkX18guu0R8e3nopXpCgszXjRh5HvAheBeMfwIjq2nnEyXPoF4w+zkOKTNoTz6ft+b067EJYbD3WKvkVpAv5EPwSdO1cLR7rSGQsR7euUGXxpPZF1CNJlUe2WOHFwtkcKhZBnqaosbvCI3fy7ycuWtYANASIDrrMXMF2PhQaCXyd/DT5refEnLm6nwHkDIy7GtvD0zSH/3ktdkVNM/xilvBqLwuW+vWqN+WBY2kHYm/UKcCb3LWofifEGuyMbnmqbDoP2Xwy1bTtP0+Se1ItmXmSe/WeOpKDAEzUm8Eahyb8rPljbbxudZsFPmzPu4DcEb/2kqjgAosQ483K1CZHn+DBeNYjpeIjQhiUaKpyxCtJudsoKSqrAPIsSyYV+YQfrkp1wVJHHcv9IBkdewLotmHVa3uF2HPTvIFPmxRB8h9Wlmi0LF03n30dcckpddlvuGO7a9WYURUi1Q2QLDknUzk+TxE5N2OvwfMF4Kc1WwQNhxxwAHz/uel6lalqu3hDtzrVeGZ8s5sA7W+LMopO6KAYI5dKVmIoD9llm8bhB1IZ+pwih38ic7uSFoNLS9Yu4Opftgp1TfrmBtVmRve3JV2BBySksDOHrcHLKQ1MSgWurr6FOXL0WZ4LTyDdO+S+jfUhezD9fpSUh3NDh4phudRJbiNL5b91Rot3AhG05C2fIq0Q5nA+fQ2E/Lm1pjbaUOHO0orJJ4RU7qFHCUlieEj5HGMmSC9dJ+q8gvdR6Fudw4BwSL3gKmMY16N4RP7VhGCkIXYN+rbUWN1RP7DYF5Y+l49IgZ6wh0WZ7a2WuldJZL3pcM5P6hlZaX5N0/G9ksGRiDQ7/U5xa8ev/S8fySk5A19mGU3QgQK9bjuHVohhNUfMgKXUDCW49aXURHjB3Muz/FCTsaejnJWZWnc6O2wrjtiJlbQnKmTqMQkw5it9QkYMjtsxJesG9iP0rb7x2PdxMoecQkYM0 5xwugEjY lrZPs8jfN0ESVInCVDG1gAI4j0dCmKCH2zzc4YUHHdCoFG3HFvki2NbF4+6qVOStDa0CRLoreHNjii3WQ4ZIeVBR1wMPQ/rZuaBH/jYkijwIbAUONeT790cfeHXeUMAE7lNrzNiUfLB/eLPfdLOSpOTbgrAnYb4Gw/K5gT1HpjgToyXN2iKZfUa8N2oqWHT3e1Q/k 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 Mon, Jul 14, 2025 at 10:14=E2=80=AFAM Vlastimil Babka w= rote: > > On 7/12/25 14:43, Vitaly Wool wrote: > > > > > >> On Jul 11, 2025, at 5:43=E2=80=AFPM, Vlastimil Babka = wrote: > >> > >> On 7/11/25 10:58, Harry Yoo wrote: > >>> On Wed, Jul 09, 2025 at 07:24:41PM +0200, Vitaly Wool wrote: > >>>> 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; > >>>> > >>>> + /* refuse to proceed if alignment is bigger than what kmalloc() pr= ovides */ > >>>> + if (!IS_ALIGNED((unsigned long)p, align) || new_size < align) > >>>> + return NULL; > >>> > >>> Hmm but what happens if `p` is aligned to `align`, but the new object= is not? > >>> > >>> For example, what will happen if we allocate object with size=3D64, = align=3D64 > >>> and then do krealloc with size=3D96, align=3D64... > >>> > >>> Or am I missing something? > >> > >> Good point. We extended the alignment guarantees in commit ad59baa3169= 5 > >> ("slab, rust: extend kmalloc() alignment guarantees to remove Rust pad= ding") > >> for rust in a way that size 96 gives you alignment of 32. It assumes t= hat > >> 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 th= an > >> 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? > >> > > > > 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 use= r requests a larger alignment, it=E2=80=99s a miss. Does that sound reasona= ble? > > So taking a step back indeed the align passed to krealloc is indeed used > only for this check. If it's really just a sanity check, then I'd rather = not > add this parameter to krealloc functions at all - kmalloc() itself also > doesn't have it, so it's inconsistent that krealloc() would have it - but > only to return NULL and not e.g. try to reallocate for alignment. > > If it's not just a sanity check, it means it's expected that for some > sequence of valid kvrealloc_node_align() calls it can return NULL and the= n > rely on the fallback to vmalloc. That would be rather wasteful for the ca= ses > like going from 64 to 96 bytes etc. So in that case it would be better if > krealloc did the reallocation, same as in cases when size increases. Of > course it would still have to rely on the documented alignment guarantees > only and not provide anything arbitrary. aligned_size() in > rust/kernel/alloc/allocator.rs is responsible for that, AFAIK. > > And I think it's not a sanity check but the latter - if the following is = a > valid k(v)realloc sequence (from Rust POV). The individual size+align > combinations AFAIK are, but if it's valid to make them follow one another > them like this, I don't know. > > krealloc(size=3D96, align=3D32) -> can give object with 32 alignment only > krealloc(size=3D64, align=3D64) -> doesn't increase size but wants alignm= ent 64 On the Rust side, you specify what the old size/align was, and what you which size/align you want after the call, and they can be anything including that combination. Alice