From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f50.google.com (mail-dl1-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A28874B8DFB for ; Tue, 12 May 2026 09:51:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.82.50 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778579516; cv=pass; b=RSNN5NgMqvB082te+6fLjuEHnEONcFIxUdqJY69y1CNw9c8YqxJcg364ByOxat7o/M1zU2+Cimx4SMJFYAyWEZvcK/71ZRGxSlvCNmB/YM7IcDfKJRwG9BGrRvBDj5hYQwIHsMHtnmt4Szky0/3HyEvnKjjHK4ysg1ts77EOBtg= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778579516; c=relaxed/simple; bh=EIsIINGplKZJmp6KyNBZmIyWQAlnRy4EfCcfLd8VLHs=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=YtypT7Fi5F0MhHcR8xf5WmWTPlXgc+tAyQ2UKp+cc3SQD+MDxVBkzIKOjDaE0P3pcFkb3dEO4yRlK1lDK1JiIxxpx1ziW/xyYIyhEDyTyRw4Elpkz3A/nqmkB6R8xRn2vKHXK+rJRdk0yGQ0wObXkFvoDHqTIQZURsCg1YYSOjM= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=l4Domj8i; arc=pass smtp.client-ip=74.125.82.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="l4Domj8i" Received: by mail-dl1-f50.google.com with SMTP id a92af1059eb24-1332772f6b3so2252678c88.1 for ; Tue, 12 May 2026 02:51:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778579514; cv=none; d=google.com; s=arc-20240605; b=NXv2sCp65e0LmnxZB9ZgXTE8+C8lYnsr29dMvUaFaME0bi9x9xPE1IQR6XQoJydB1v hzf9VJY11hF6qEuGFE6+UIXEKcay3hf6IfiKUPVkEVK00HNLpUlXH3vzFCDAWgtXZdNy hdo6h0AL3KBG7Y+ru4javwW33KcUsNluanyrmgFbdX0fPRFQlXzHoy5nofs6tszJqqXp 46PwxxmEuNDIeKvj3v1o4AzbdsFkh82mpxyJT4C+KtroUbxBN5pO7sqHzcuAE9yip53/ 1UROWt0IUg8ec49XbMzrigKHA0597FjWQmnIBM80yI88YuMNOap1nvN7V0mB/QdBewQ2 wqJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=+ec8Gp9KIgloqxfI4Ah9RgcAxU70GC5qHU2EuM04KDM=; fh=TiAvICFifta6Uq+GNjxwBM9cuSjNrjSXbxRdw4H1MUk=; b=OdBzITpthHFL1Qtql/2Da8IvMN3TmeRvsrUBukYWibXtiJ/1HmfIrwo6rvxE+C4Ywu 2nN5IgsAMBqxo9yl4pmA6q1X5chgCEkf724WPrYj1TFlnWxkBqg6yqtDRmvtLdXoQU6a sDLz9MFt58BxfIicZEniEVZsLqpSkJshazAIoWuEnwn5aCrxSNHzLy4baBT4kX/N4hKM V7k/XepCgf9AY0d3mvNK+Gu5OnGlZO50LVqVa6klMW1eMTj3LozhH1X/BYtJABlEKpKr f0DYwwl7zqmXhm2yNd3nI+Z0VQRDdg39UdJgZByMY4tP4VOBIMga/SgNwKqPUSw6wy2G 1dmw==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778579514; x=1779184314; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+ec8Gp9KIgloqxfI4Ah9RgcAxU70GC5qHU2EuM04KDM=; b=l4Domj8inxGVm5Bp7+5ucV8jYDuDKDIDjlyjS1jwCBey1DhmQq2KHip6/hbkWQ/TvO Q1MA5cX3zO77Ija8uWGiArMgJoYCjjso89pSTD1kwhwltdenAYfyAZij0e8LK8NqqsQ0 2qFwADsdr3UR705KNj9wCq8ibpmjlhHADEtKJpjG7IOSdwVWCQSEPRZGxpwSFnix3dlk R5YozBg0f83Y54jpd2V5ey20pufnemPji+tSdtu4jwNAd0+ZHp+bd/pxvODVhI6uVFNR nKsrTns1tBYe8ONcSZPXNIdPfDIyDZrJwmuoMu1rDMVlvyhok+43Fv7262BYxbQgD4tS t2Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778579514; x=1779184314; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+ec8Gp9KIgloqxfI4Ah9RgcAxU70GC5qHU2EuM04KDM=; b=hchExkX5b4w48UHdr1aQB7ixHyoIcgJIbyB5StD1pYFe2Kc8OtKxBBxRxQaeqxt36Y ViNHmhgIyxdrQThi1HAq0DoRLPLEmJrlWsNLQJF8AAfh0Hl8vbZpi1cMiV5P0++PWen4 IJ0mwNpFOgzHhbvKyzz7d0U3ZEyiZf5Kcm00J+thuGfM+bRHMJh4JVlE5WXkjOJr/SHK mBmkcLWK6K5dF/Te9CI+hnOzX7qeSEKN9VIP6YC11VwH1BzfYQQ8AvZmRx/B/8Vjc0nN 8aULhb2Ti9RSN5FAKFY7XQp6+WAIMOIzaFGJf9pwzZ08A4Id+SMkTfb3rkLuLydNpVQu biRA== X-Forwarded-Encrypted: i=1; AFNElJ8YGmdgzihtNf4+O/TcOj/qEUnWuOdmog+NGN4WmKr73YamZIN6liOEKjagL4smR65wB89xDeHUV9qAyw4=@vger.kernel.org X-Gm-Message-State: AOJu0YyTYt2KWfPGBsEQj4QFmkL76zesH1OPe48FTICrBAFDRMi7M8u6 XYeGc+RDDFG64l8dQbyhKJT2WfmNFZ2lG73z24W44NP/E4rVxgJUwv5uJjTx1xN+OkVWcK3paXV 42uaP7US2o19eMqYKdi4fO62ZHYA/bYyVwTppPfuV X-Gm-Gg: Acq92OGxZmwQjnRRIK4noXd4UG986sr0N/J2oOFlHyTEL84/jqriBKLjYB3naY4iNAN hAlXQKkQA4vKPwEEWTXq9ROB0Nu1NcWh5Jyt1e71pbbRBXwmkoTrsSKBYgluhTI6J//piGrp5xZ GWR+M+kcCY7OYtTzlpyUKCXoQoz3F6qOrGppeQQsbxl8z526hRP9ZzCmRFVue/6o/MhdjqKMRsj jk7FgFjIvVyuqMwbBoDRvoAOB/9AyWLlkskndcinC2Dl8QHacWv1zXCqzVKlhMsV1QVRKtOg/jz wvpn2L/STUH1yx6i5C6RzxIZsTWLHnchOPpvgt7d7Bbx7djg X-Received: by 2002:a05:7022:38c:b0:128:d20a:2f40 with SMTP id a92af1059eb24-13344c4307bmr1461470c88.8.1778579513098; Tue, 12 May 2026 02:51:53 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260511200136.3201646-1-elver@google.com> <20260511200136.3201646-2-elver@google.com> <3z5unwqxty4qq2siingxdijbk642te7kf26ba4ff2xsmyptgq5@i6bxrvkfbve4> In-Reply-To: <3z5unwqxty4qq2siingxdijbk642te7kf26ba4ff2xsmyptgq5@i6bxrvkfbve4> From: Marco Elver Date: Tue, 12 May 2026 11:51:15 +0200 X-Gm-Features: AVHnY4J9rWhb6ZrnXllLEE_U0YQh3r6D8w8ra1G0CJOzHs8wrDs9DHipy-uAw-w Message-ID: Subject: Re: [PATCH v4 2/3] slab: improve KMALLOC_PARTITION_RANDOM randomness To: "Harry Yoo (Oracle)" Cc: Vlastimil Babka , Andrew Morton , "Gustavo A. R. Silva" , "Liam R. Howlett" , Andrey Konovalov , Bill Wendling , David Hildenbrand , David Rientjes , Dmitry Vyukov , Jann Horn , Justin Stitt , KP Singh , Kees Cook , Lorenzo Stoakes , Matteo Rizzo , Michal Hocko , Mike Rapoport , Nathan Chancellor , Nick Desaulniers , Roman Gushchin , Suren Baghdasaryan , linux-hardening@vger.kernel.org, Nicolas Schier , Dennis Zhou , Tejun Heo , Christoph Lameter , Hao Li , "Liam R. Howlett" , Alexander Potapenko , Miguel Ojeda , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com, llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" On Tue, 12 May 2026 at 07:13, 'Harry Yoo (Oracle)' via kasan-dev wrote: > > On Mon, May 11, 2026 at 10:00:49PM +0200, Marco Elver wrote: > > When using CONFIG_KMALLOC_PARTITION_RANDOM, _RET_IP_ was previously used > > to identify the allocation site. _RET_IP_, however, evaluates to the > > caller's parent's instruction pointer rather than the actual allocation > > site; this would lead to collisions where a function performs multiple > > allocations. > > > > With the generalization to kmalloc_token_t, we now generate the token at > > the outermost macro, and using _THIS_IP_ would fix this for all cases. > > > > Unfortunately, the generic implementation of _THIS_IP_ relies on taking > > the address of a local label, which is considered broken by both GCC [1] > > and Clang [2] because label addresses are only expected to be used with > > computed gotos. While the generic version more or less works today, it > > is known to be brittle. For example, Clang -O2 always returns 1 when > > this function is inlined: > > > > static inline unsigned long get_ip(void) > > { return ({ __label__ __here; __here: (unsigned long)&&__here; }); } > > > > To provide a reliable unique identifier without breaking architectures > > relying on the generic _THIS_IP_, introduce _CODE_LOCATION_: it resolves > > to _THIS_IP_ where architectures provide a safe implementation, and > > falls back to a zero-cost static marker where _THIS_IP_ is broken. > > > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120071 [1] > > Link: https://github.com/llvm/llvm-project/issues/138272 [2] > > Signed-off-by: Marco Elver > > --- > > Looks good to me, > Reviewed-by: Harry Yoo (Oracle) Thanks! > with one suggestion below. > > > --- > > include/linux/instruction_pointer.h | 24 ++++++++++++++++++++++++ > > include/linux/slab.h | 2 +- > > 2 files changed, 25 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/instruction_pointer.h b/include/linux/instruction_pointer.h > > index aa0b3ffea935..ea5bc756bd99 100644 > > --- a/include/linux/instruction_pointer.h > > +++ b/include/linux/instruction_pointer.h > > @@ -8,6 +8,30 @@ > > > > #ifndef _THIS_IP_ > > #define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; }) > > +/* > > + * The current generic definition of _THIS_IP_ is considered broken by GCC [1] > > + * and Clang [2]. In particular, the address of a label is only expected to be > > + * used with a computed goto. > > + * > > + * [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120071 > > + * [2] https://github.com/llvm/llvm-project/issues/138272 > > + * > > + * Mark it as broken, so that appropriate fallback options can be implemented > > + * for architectures that do not define their own _THIS_IP_. > > + */ > > +#define HAS_BROKEN_THIS_IP > > +#endif > > + > > +/* > > + * _CODE_LOCATION_ provides a unique identifier for the current code location. > > + * When _THIS_IP_ is broken (generic version), we fall back to a static marker > > + * which guarantees uniqueness and resolves to a constant address at link time, > > + * avoiding runtime overhead and compiler optimizations breaking it. > > + */ > > +#ifdef HAS_BROKEN_THIS_IP > > +#define _CODE_LOCATION_ ({ static const char __here; (unsigned long)&__here; }) > > nit: perhaps it can be __initdata to free these after boot? > ... if we want to save actual memory allocated rather than the > vmlinux size. > > apparently ".init.bss" is a not thing :( Not sure - it might cause CONFIG_DEBUG_SECTION_MISMATCH warnings. Also, if this memory is reclaimed, it may be reused for kernel modules, at which point there's a chance for collisions.