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 B9EDB3BD228 for ; Thu, 4 Jun 2026 05:46:39 +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=1780552000; cv=none; b=SBwqmvNdl96I/GmGAjGa+ZGHfpDZpy7EuHdG26se8wRsRELauxyqjNzTnhMTHOfIQcUN2hxwMPCy1QtvvswCAfoeTc8t5Pt34kVHNN8yusqa23r66pFhl8hgvucduuYdjuHzYAvt5Hz+Nb0+pTnTdgXLkN2Ox4F9Euc7P7UDNT0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780552000; c=relaxed/simple; bh=HaCQSUpFjPicZ02MKkifasHWlZLHdAqxQ2CZNYVXYA8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=oqedU7MnzHz+erENHOSEpFZ7KCOFTliQMNgGKGo1c7e4KonuMKj3Hnz/VguGPXmowfy6KUnYart1bkPztnoa+zNhXMNgtr1mUPk+QR2TJke6dJwR9lej7C7p2o4edTsUZA5AEw5eQr99z6WDYw3QzcyUn5l8KWtXrkooXQuMMH8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cmQAR+EA; 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="cmQAR+EA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0973E1F00893; Thu, 4 Jun 2026 05:46:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780551999; bh=I3QgRkPokzKxJvWdmi5M8w57vRhF+d7yuw6VZVwG06A=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=cmQAR+EAiirJp/9QBFi/3tiz60puqWAtMXmtq5fRCK4sa1SwpFtaJ9XPHsll3VBBQ spblJV6uPsLZcES3o6LVBZwq9haeqmbGvfqQiYCf0G+F566PQvT9m0RNdPHeDRib3l OBGMukQK7tWC77TAfiL4i738HoUblMDPTDhRW9EIcFPFox/AaqoJh6yfYbo9J3gcF4 nbsJ0Uk2M2SqvVLmmlk5UGKhT1rcOf9vYVHCj9aVitLpYtqPJGtJ2ca9m2RnVxOC9/ E+wu4KQUJMWZc15RSG0xQDBNo3K8fJHt/oQrwToZ4/oU7zT2YZ+xTEkV6MQi11kKh8 PVpcA7SANhHyA== Message-ID: <07f55792-c83f-433c-bb16-58a5824d1dd7@kernel.org> Date: Thu, 4 Jun 2026 14:46:27 +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: preserve original size in _kmalloc_nolock_noprof retry path To: hu.shengming@zte.com.cn, vbabka@kernel.org, akpm@linux-foundation.org Cc: hao.li@linux.dev, cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, zhang.run@zte.com.cn, cai.qu@zte.com.cn References: <20260603211011530GqLSXP_rgcuQdR47IGQLL@zte.com.cn> Content-Language: en-US From: Harry Yoo In-Reply-To: <20260603211011530GqLSXP_rgcuQdR47IGQLL@zte.com.cn> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ZZJvR020eA0i0ukYK75K7ntc" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ZZJvR020eA0i0ukYK75K7ntc Content-Type: multipart/mixed; boundary="------------QBU0MuEE9lWw6oOdiF27OnpM"; protected-headers="v1" From: Harry Yoo To: hu.shengming@zte.com.cn, vbabka@kernel.org, akpm@linux-foundation.org Cc: hao.li@linux.dev, cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, zhang.run@zte.com.cn, cai.qu@zte.com.cn Message-ID: <07f55792-c83f-433c-bb16-58a5824d1dd7@kernel.org> Subject: Re: [PATCH] mm/slub: preserve original size in _kmalloc_nolock_noprof retry path References: <20260603211011530GqLSXP_rgcuQdR47IGQLL@zte.com.cn> In-Reply-To: <20260603211011530GqLSXP_rgcuQdR47IGQLL@zte.com.cn> --------------QBU0MuEE9lWw6oOdiF27OnpM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/3/26 10:10 PM, hu.shengming@zte.com.cn wrote: > From: Shengming Hu >=20 > _kmalloc_nolock_noprof() retries from the next kmalloc bucket when the > initial allocation fails. The retry currently reuses `size` as the > bucket selector and overwrites it with s->object_size + 1. >=20 > That value is later passed as the original allocation size to > __slab_alloc_node(), slab_post_alloc_hook() and kasan_kmalloc(). On a > successful retry this makes KASAN/slub-debug observe the retry bucket > selector rather than the caller requested size, potentially widening th= e > valid kmalloc range and hiding overflows. Good catch! > Keep a separate `bucket_size` for choosing the retry cache and preserve= > `size`. >=20 > Fixes: ("slab: Introduce kmalloc_nolock() and kfree_nolo= ck()") > Signed-off-by: Shengming Hu > --- I want to note that this conflicts with Vlastimil's work-in-progress feature [1] where it separately stores orig_size in struct slab_alloc_context which naturally solves the problem. [1] https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=3D= b4/slab_alloc_flags No strong opinion on whether to queue this patch and then rebase Vlastimil's work on top, or wait for Vlastimil's work to solve the problem instead... > mm/slub.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) >=20 > diff --git a/mm/slub.c b/mm/slub.c > index 67abbbf68fc1..6a2b3ade3611 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -5350,6 +5350,7 @@ EXPORT_SYMBOL(__kmalloc_noprof); > void *_kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t gfp= _flags, int node) > { > gfp_t alloc_gfp =3D __GFP_NOWARN | __GFP_NOMEMALLOC | gfp_flags; > + size_t bucket_size =3D size; > struct kmem_cache *s; > bool can_retry =3D true; > void *ret; But in either way, I think it's more straightforward to introduce orig_size as a variable to keep the original size and pass it to __slab_alloc_node(). > @@ -5372,9 +5373,9 @@ void *_kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(si= ze, token), gfp_t gfp_flags, in > return NULL; >=20 > retry: > - if (unlikely(size > KMALLOC_MAX_CACHE_SIZE)) > + if (unlikely(bucket_size > KMALLOC_MAX_CACHE_SIZE)) > return NULL; > - s =3D kmalloc_slab(size, NULL, alloc_gfp, PASS_TOKEN_PARAM(token)); > + s =3D kmalloc_slab(bucket_size, NULL, alloc_gfp, PASS_TOKEN_PARAM(tok= en)); >=20 > if (!(s->flags & __CMPXCHG_DOUBLE) && !kmem_cache_debug(s)) > /* > @@ -5408,7 +5409,7 @@ void *_kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(si= ze, token), gfp_t gfp_flags, in > */ > if (!ret && can_retry) { > /* pick the next kmalloc bucket */ > - size =3D s->object_size + 1; > + bucket_size =3D s->object_size + 1; > /* > * Another alternative is to > * if (memcg) alloc_gfp &=3D ~__GFP_ACCOUNT; --=20 Cheers, Harry / Hyeonggon --------------QBU0MuEE9lWw6oOdiF27OnpM-- --------------ZZJvR020eA0i0ukYK75K7ntc Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCaiERMwAKCRCGXBN6rc5S 1jRPAP9wDZ921494EYcGs/+HDS6VMmFMMG9OyxCua8hMUG+FlQEArOf1WRiBjRD6 HuTBcbGntszY/MEvv+O4sFbgjbThVA4= =EksB -----END PGP SIGNATURE----- --------------ZZJvR020eA0i0ukYK75K7ntc--