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 4FEDD37267F for ; Wed, 1 Jul 2026 04:31:04 +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=1782880267; cv=none; b=CtzPhfj9jPjTE7LC0cBeoamonSTJtLQBGOWprKA+6LHTnd5XOGahzEYDddDTim5OryzgEHqYwnvcYsqgl6rf15m6tYO43Py/ty1lx+TDGFXhjSCo4VLhf+esMNFui7xMy6cDwge6d88VzH8JbcsN3FfbHY9XX5uhbJce99avPfI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782880267; c=relaxed/simple; bh=i9qtdx7tUGdeo+ILqCr9vLvhZg6C/ZjQkVuCx7sLM1U=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=Ps33np/TPpk7ZUMbea0u///MwsMol/0yEbf9DVesfW187eVNRs+9yhJ1pJVWOekJHvdYCftKgKxRWXmr8w8uiOJPvczmQGZdED3NKjM1M7+YUBeJTngLn6/AN4rz8JqJVf4UPQMNaICiiKgkRjO2FCD6Rpdnfuo+pB7oktokrs4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RbxhsYd/; 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="RbxhsYd/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 468D91F000E9; Wed, 1 Jul 2026 04:31:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782880264; bh=tloZl3rnZnNSdyPLKmQcYCzAFnf6p2H8ExB+//cJ/SE=; h=Date:From:Subject:To:Cc:References:In-Reply-To; b=RbxhsYd/pL7HZId6hk3uZpF5v0dOdJEWm36wI/FjlErI9r9V0KuTX0C5MO3fPuIEH knAido9Q/1dK2w9i7uwcwX7BT/GhbeFHVRGiFsxmdYKzo2YVvQwnt2zSh9CbDWYwy7 RAvFYXhUis9g7W34Ts+YSFZpXm8GPHSmejCGEZbfeZPjgi9wRgKwH8+Wn1S+DE57MA bhdcdiVvzRVZv/TCRM2hGoqD/8cyJ3k/FnxxJmHZD5MmNRQobCR3eSzMtaOnuD/Aar qfgLmTOdWhRfRKI0JeH36T921XSFO8B1nmXxw4L1429uQj77mk6EYo05ZUeJjMJs5a 0vpVhsFxucSSw== Message-ID: <9a139365-28e6-4f1e-b35b-7f6091e9aa14@kernel.org> Date: Wed, 1 Jul 2026 13: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: Shakeel Butt , "Vlastimil Babka (SUSE)" , 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: <62969830-4b1f-483d-8fa9-9ce487568570@kernel.org> <39a79576-dcae-4b66-9478-c81dfe676699@kernel.org> <5ebd3c4a-5c06-43b4-ab0a-7a8f0396c84c@kernel.org> Content-Language: en-US In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------PsZRKWkrNzHxq1aE0n858PAN" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------PsZRKWkrNzHxq1aE0n858PAN Content-Type: multipart/mixed; boundary="------------Ax2loyT0t0fFBrA0ODoBSwHw"; protected-headers="v1" From: Harry Yoo To: Suren Baghdasaryan Cc: Shakeel Butt , "Vlastimil Babka (SUSE)" , 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 Message-ID: <9a139365-28e6-4f1e-b35b-7f6091e9aa14@kernel.org> Subject: Re: [PATCH] mm/slub: serve slabobj_ext array from a strictly larger kmalloc cache References: <62969830-4b1f-483d-8fa9-9ce487568570@kernel.org> <39a79576-dcae-4b66-9478-c81dfe676699@kernel.org> <5ebd3c4a-5c06-43b4-ab0a-7a8f0396c84c@kernel.org> In-Reply-To: --------------Ax2loyT0t0fFBrA0ODoBSwHw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/1/26 8:55 AM, Suren Baghdasaryan wrote: > On Tue, Jun 30, 2026 at 8:27=E2=80=AFAM Harry Yoo wr= ote: >>> I'll also give it some thought to see if there is maybe a different >>> way to fix this that would be easy to backport. >> >> Thanks, let's discuss! >=20 > So, below patch is based on stable linux-7.1.y branch and I think it's > the simplest backportable way to fix this issue. Build-tested only, so > use just as a prototype. Thanks! > Not sure if making buckets parameter > unconditional from CONFIG_SLAB_BUCKETS has side-effects... Increased binary size and register pressure IIRC https://lore.kernel.org/linux-mm/d0fe363c-2e8f-44a4-9b64-3fa3ba9a5773@ker= nel.org > Attaching the patch as well since I'm sure gmail will butcher the tabs.= >=20 > The fix for 7.2 should be much simpler using a new flag in > kmalloc_flags() for obj_ext vector allocations and serving these from > a dedicated cache. =2E..which means, in 7.2, it will have a new KMALLOC_TYPE and now kmalloc_type() and kmalloc_slab() will select the cache based on GFP flags AND slab's alloc_flags (based on SLAB_ALLOC_NO_RECURSE, this is new) Hmm, wait. We can do that in pre-7.2 kernels, by teaching kmalloc_type() and kmalloc_slab() select the new KMALLOC_TYPE based on __GFP_NO_OBJ_EXT? e.g.) Select the new KMALLOC_TYPE when KMALLOC_NOT_NORMAL_BITS is not set AND __GFP_NO_OBJ_EXT is set. This doesn't require kmem_buckets and should be much simpler. > Please let me know what you think: So I think we don't need kmem_buckets for minimal fixes? > --- > include/linux/slab.h | 42 +++++++++++++++++++++--------- > mm/slub.c | 61 +++++++++++---------------------------------= > 2 files changed, 45 insertions(+), 58 deletions(-) >=20 > diff --git a/include/linux/slab.h b/include/linux/slab.h > index 2b5ab488e96b..2d4a6e3064a3 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -618,6 +618,10 @@ static inline unsigned int arch_slab_minalign(void= ) > #define RANDOM_KMALLOC_CACHES_NR 0 > #endif >=20 > +#if defined(CONFIG_MEM_ALLOC_PROFILING) && defined(CONFIG_SLUB_TINY) > +#define OBJ_EXT_VEC_CACHE > +#endif Should be || instead of && > /* > * Whenever changing this, take care of that kmalloc_type() and > * create_kmalloc_caches() still work as intended. > @@ -646,6 +650,9 @@ enum kmalloc_cache_type { > #endif > #ifdef CONFIG_MEMCG > KMALLOC_CGROUP, > +#endif > +#ifdef OBJ_EXT_VEC_CACHE > + KMALLOC_OBJ_EXT_VEC, > #endif > NR_KMALLOC_TYPES > }; > @@ -654,6 +661,18 @@ typedef struct kmem_cache * > kmem_buckets[KMALLOC_SHIFT_HIGH + 1]; >=20 > extern kmem_buckets kmalloc_caches[NR_KMALLOC_TYPES]; >=20 > +#ifdef OBJ_EXT_VEC_CACHE > +static inline kmem_buckets *obj_ext_vec_buckets(void) > +{ > + return &kmalloc_caches[KMALLOC_OBJ_EXT_VEC]; > +} > +#else > +static inline kmem_buckets *obj_ext_vec_buckets(void) > +{ > + return NULL; > +} > +#endif This is bit weird because it creates a new kmalloc type while using kmem_buckets. Conceptually, a kmem_buckets can be thought as a KMALLOC_TYPE, but created by kmem_buckets_create(). Security folks introduced this to isolate some kmalloc allocations from of varying size (e.g., memdup_user, msg_msg where users can control the size of allocation) from the rest of kmalloc caches. > /* > * Define gfp bits that should not be set for KMALLOC_NORMAL. > */ --=20 Cheers, Harry / Hyeonggon --------------Ax2loyT0t0fFBrA0ODoBSwHw-- --------------PsZRKWkrNzHxq1aE0n858PAN Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCakSYAAAKCRCGXBN6rc5S 1qO4AQC3xLA+xOtG1pNuADu7EGYWVEy2miVP1+ORubgaZsY9JQEAh0/HUloSjGui AI/lb5skTmjGGjyTesbuRsZNbIqA+Qs= =egrm -----END PGP SIGNATURE----- --------------PsZRKWkrNzHxq1aE0n858PAN--