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 CB7443D994 for ; Tue, 30 Jun 2026 02:31:00 +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=1782786663; cv=none; b=iwsoZcrfwEK3O2fk4bh1iVtnTJnSF8eF/NCbJuak9MUpE2fHBYGzvayRAbD0hU8iBXaS4R1FMVIQrbZWImHvBAJle16XUXZf54RPO/SUejHQwCZc5fzkeh0IyuYpz2AqmSQYUHnCUNAkwVuR96DK73dfS/l1CdVox7tVf0qhhRI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782786663; c=relaxed/simple; bh=z1AYYcrTrMl35mTqFYyKZGF9UkcWy/md1/1jSJ+bTTg=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=kA/0Qr5IhOTMsRQRjfEBZBS1rf8vgHuoLmJ/rxstqRq50JSnZrmGzhOYSD64h9z1TWdlJX4YDGIM9XRSOYYZRgf1pBF3q9EReTkN0f3B9r9B0zHHFM7trav1gpTDc9jFlwPqwB5GTrnI7c9xqArEMa0tsEyG4r6lNTCdX0tiXR4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iy6tI7kn; 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="iy6tI7kn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7398A1F000E9; Tue, 30 Jun 2026 02:30:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782786660; bh=GbR3UdRqFNJnR9UD31Nfq5nT1QTRhAajYqk/CATaIzw=; h=Date:From:Subject:To:Cc:References:In-Reply-To; b=iy6tI7knK+LFetvQngQtlx01BusxlQItmdkz4xEmd6PyQWogDs+Oc8+Cw4XZvMS9P P1qyQfN8FIjpUZ59CtztedB2i8NpKpRsBjFCe+gF/GmwHovY2PaHRsH3bosQpa0AcR J1VAulYSGOosfbMfYs28KfBpO9zkktIUHrp5irJt/OeQHTGyLrcLIE9VaPMedxFJnK pKQAAnKxzJMAAgR+15e1u2LdHjxJWIHfDhvRc9xEDq09/WdTvClR+DmgB1c3vZH4kH XxApP7xgYVcN672K4pbnymHpmdjZFjREa5e4j7g+FmziHXPpSqch/GSj8BaiyWLVrS 9nWkFUerjfz1A== Message-ID: <62969830-4b1f-483d-8fa9-9ce487568570@kernel.org> Date: Tue, 30 Jun 2026 11:30:56 +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 From: Harry Yoo 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> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/29/26 1:28 PM, Suren Baghdasaryan wrote: > On Sun, Jun 28, 2026 at 8:57 PM 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 provides >> 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 profiling or SLUB_TINY are >>> enabled to avoid new caches when not needed. Does not seem too complex >>> 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 parameter to >> the kmalloc slowpath. Probably it'd be worth introducing a dedicated >> 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-ce1146d140fb@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. > Just throwing this as an> option. I haven't looked closely into > SLAB_BUCKETS yet, so that might > be indeed a better direction. -- Cheers, Harry / Hyeonggon