From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A08E13E00A3 for ; Tue, 30 Jun 2026 04:42:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782794548; cv=none; b=sdwGsIit/1lQQ+8iAof8CMzeqM32FC1sRDubJKXOOo0SCUsFe7TiidII0YIqWTik7Ib7fiXPbypWV2g2Cbs09n6lF42pa1FOo0VfnQlla1Z9hnwEOq44NMk/f1EBKNyiHl92vIQWNeaVMRYik/j5OKS1fGVQETlRHByMWmiIYZc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782794548; c=relaxed/simple; bh=+qh955Qd4Drb3fQbnG9SkOxH44b0bmvRsJ2O0htVdBs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=igEc2I7g6UUy/DpEl4/yraGsm0+mETtacM2NFfZ0kieZZi1JBYP5zt3wF2T550mqU0Nv9nvOPb7q1iT7YhHx2ddDKp03G+Yx/Wor59Y1a7HRmRJgzc37yKCE/l3ia8iSEAFkEYsDdgfdl7Zmx87thUX4f6lgkOjoXWiMvjWt/GI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dh/y1LSB; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dh/y1LSB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2053E1F000E9; Tue, 30 Jun 2026 04:42:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782794545; bh=1cPiJvYZHb7avfM0My/PdqUI5x5yrUyDFJ25Fg7K9NA=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=dh/y1LSBjjm9REMGrHHS6hzA5F8VlHjSV+hsD3XUt9gu1RbwqhxFzbwYg/J1hzcXH TrtHo1ED/uxwl1t/6QHrreM9dU/4B48NtYBqLo1mEsdv/VaEIBoq55lZgFx0xNWOH+ BIr7WuAyTSQQCZeqkHECIumyCEuS+QfZ9HdJoZ+83/BQY3nDaBcishhFrd984b4khR 5Tvj5eSdV+64nG2mtEZDM1Iqgby7NvBIRoauhKgtbz3FV8g0W0AILGoaN+/aLtx8La sAVsyUsnjSq7GrhCBOuPU9S7Mqa8CUPOP5OFeMoc2s+EefpYE4GOGmFy/SItFq8l/y arjgSo3tk6kSA== Message-ID: <39a79576-dcae-4b66-9478-c81dfe676699@kernel.org> Date: Tue, 30 Jun 2026 13:42:20 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/slub: serve slabobj_ext array from a strictly larger kmalloc cache To: Suren Baghdasaryan Cc: "Vlastimil Babka (SUSE)" , Shakeel Butt , Andrew Morton , Roman Gushchin , Hao Li , Christoph Lameter , David Rientjes , Usama Arif , Meta kernel team , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Danielle Costantino , Kees Cook References: <20260625230029.703750-1-shakeel.butt@linux.dev> <62453403-954c-4cf1-8924-6d38184b0810@kernel.org> <09267187-6c85-438f-8791-4cce8d07892a@kernel.org> <68122038-e8e0-47ed-82f8-cb6a23e4658e@kernel.org> <62969830-4b1f-483d-8fa9-9ce487568570@kernel.org> Content-Language: en-US From: Harry Yoo In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/30/26 1:39 PM, Suren Baghdasaryan wrote: > On Mon, Jun 29, 2026 at 9:38=E2=80=AFPM Suren Baghdasaryan wrote: >> >> On Mon, Jun 29, 2026 at 7:31=E2=80=AFPM Harry Yoo w= rote: >>> >>> >>> >>> On 6/29/26 1:28 PM, Suren Baghdasaryan wrote: >>>> On Sun, Jun 28, 2026 at 8:57=E2=80=AFPM Harry Yoo = wrote: >>>>>> I think adding a new KMALLOC_TYPE would be the cleanest way to fix= >>>>>> this recursion problem once and for all. This size bumping and the= >>>>>> special case of SLUB_TINY are quite confusing. >>>>> >>>>> As mentioned by Vlsatimil, in the long term, using SLAB_BUCKETS >>>>> infrastructure would be more straightforward than new KMALLOC_TYPE >>>>> because (I think) the kmalloc type is decided purely based on GFP >>>>> flags and we need to somehow work around that. SLAB_BUCKETS provide= s >>>>> a nice abstraction to do this. >>>>> >>>>> Luckily, SLAB_BUCKETS is introduced in v6.11. >>>>> Unfortunately, SLAB_BUCKETS is optional. >>>>> >>>>>> We could define that> new KMALLOC_TYPE only if memory allocation p= rofiling or SLUB_TINY are >>>>>> enabled to avoid new caches when not needed. Does not seem too com= plex >>>>>> but maybe I'm missing something? WDYT? >>>>> >>>>> I think we need some enhancements to achieve that with SLAB_BUCKETS= >>>>> >>>>> 1. Rename SLAB_BUCKETS to SLAB_BUCKETS_HARDENING >>>>> (w/ SLAB_BUCKETS being a transitional config for _HARDENING) >>>>> >>>>> 2. Make the SLAB_BUCKETS infrastructure unconditional, >>>>> but the decision is made at runtime: >>>>> >>>>> 1) actually creating a kmem_buckets vs. >>>>> 2) falling back to kmalloc. >>>>> >>>>> 3. kmem_buckets_create() creates kmem_buckets only when >>>>> SLAB_BUCKETS_HARDENING is enabled. >>>>> >>>>> 4. SLUB decides (not) to create kmem_buckets for internal use >>>>> during the boot process. Use the kmem_buckets for obj_exts >>>>> array allocation. >>>>> >>>>> Side note: this would unconditionally add the kmem_buckets paramete= r to >>>>> the kmalloc slowpath. Probably it'd be worth introducing a dedicate= d >>>>> entrypoint for kmem_buckets instead. >>>> >>>> Yeah, this sounds quite complex. >>> >>> I think it's not that complex, but quite some churn, yeah :) >>> >>>> Maybe we could use the new> kmalloc_flags() introduced by Vlastimil >>> > in [1] to avoid using GFP >>>> flags to indicate that we want to use this new KMALLOC_TYPE? That >>>> seems simpler, >>> >>> That indeed would be smaller changes. >>> >>>> though it's not backportable because kmalloc_flags() is> brand new. >>> >>> Right, I didn't seriously consider that option as I was (mistakenly) >>> assuming you or Shakeel would want to backport it. >>> >>>> [1] https://lore.kernel.org/all/20260615-slab_alloc_flags-v3-0-ce114= 6d140fb@kernel.org/ >>>> >>>>> >>>>>> If it is more complex than I imaging then I'm fine with Shakeel's >>>>>> approach as a temporary fix. >>>>> >>>>> Since above requires quite some changes, I'd say let's proeed with >>>>> the fix (since it's one line of code change that fixes a bug), >>>>> and then see how we can make SLAB_BUCKETS changes as minimal >>>>> as possible for backporting? >>>> >>>> I was thinking Shakeel's approach for backports and >>>> kmalloc_flags()+KMALLOC_TYPE going forward. >>> >>> Oh, I misread it then. >>> I was assuming it's critical enough to bother backporting. Ah, here I meant backporting either the kmalloc_flags()+KMALLOC_TYPE or SLAB_BUCKETS approach. >> Yes, it's worth backporting, so we can merge Shakeel's change as is Right. >> and then once Vlastimil's patch is merged we can implement the new Vlastimil's patch has already landed mainline, by the way :) >> KMALLOC_TYPE as a replacement. >=20 > And Shakeel's patch is easily backportable. Yes, of course! --=20 Cheers, Harry / Hyeonggon