From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f44.google.com (mail-dl1-f44.google.com [74.125.82.44]) (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 DF7AD38239E for ; Fri, 15 May 2026 13:24:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.82.44 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778851498; cv=pass; b=s/mxKnNaTOjWivhNNm/4ZtMd9Kzp85/CzKBiAZE2ZaeltBSyxzTXONIZFi64Hrs4spy8l8G5I6UvCEhyPWUpvcT979+4n7NjkvOOEED9sIMMIQ6gjzIOMP/hccyukhcH7upt1lWAT1roYGgGCjsRnJF5mMo/dL+EU/FGUuVmKDU= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778851498; c=relaxed/simple; bh=9S/wyijREW7prxTs0cpddfr7+xTXmq79rJi7zvdyiio=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=af3baTJfIfRKmgQusHwvmsnKPRhyJtwdWo7ZN+xhHmZXTdu4iMUv16FP6+d6YRqfVOg1EApe7znnLcHSpAoDyMhIeNCtZD5Oadmf/uB1U1OvV5K2AitUseKsS3yCcSMX8+zIpr70iE19OLPtz094d25prEjk24wip2yv/b8S+fg= 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=Qge02j5Y; arc=pass smtp.client-ip=74.125.82.44 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="Qge02j5Y" Received: by mail-dl1-f44.google.com with SMTP id a92af1059eb24-12c19d23b19so15209753c88.0 for ; Fri, 15 May 2026 06:24:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778851493; cv=none; d=google.com; s=arc-20240605; b=RTZgVYow0Y5uLD1rmJGLXc4c7qtIXUyqni/nLfMPfkux3FV8qSaSQ1iOrfVrU2fio/ jNFlrTfTzmf+IWE7hcWVUms0OySPHNTF2zTAAxGh92xOMz3116az1+PJUInLk8/1uXa7 8VHsGzFVO4AL4vaG/RZTZuSHKH9k6YDHoMSUUoNVFgk3dI1Sce2mqCPbrfV16NQxBQzG GN1h/CHW7XKk+vy+S65BQQMKGzgbKLCY0wLv7yJGXYNG+OkwXQbav4rOn4GuYHME6N84 kuFG1A0mozjxvXEbYyyBvMrfRSRRNq19hwyBwtG4o7BnULZpcVwvy8b9IFzEsPikUmma 6mJA== 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=kJkIJ9MSSyAx7AMR5IamH1iN68B4UTFJP9CxVTr4bw8=; fh=EOOqSl+QgSPGSGrNUZVvErXMlTa5SkZp9rfpSl7sD+M=; b=hwY0+Yy02rlMjISvYnVd472zSs6OTWA0K5MIXz4qxzhesP6emwKkWMkwEPbkmBqdhy FwMgpcqQ20dKzzfr3L4pdqiqCD7BwNwt9DL1XEhThzFS5xjQBDQgmMhxPM5OaCyvAuBw FKOia056Ol3aL/Cf/30OvmCjBfAx7CDrZaEyNoskjF0QrXiXEeIjVt0uzlyAiQV05s9u 7uYginY8ty/JyFZ2wjQvUBX7J0gK0czu9Ybw5v968Vnj9ZaqRMaUC/WSRIz76+zXfVYm QCNR8Q0a9q7+RCDMTCgEz1phqD7ccjSIQs0eDeM5z0E/4+HZONcsvORRDKfOzPCv5/i9 QzhA==; 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=1778851493; x=1779456293; 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=kJkIJ9MSSyAx7AMR5IamH1iN68B4UTFJP9CxVTr4bw8=; b=Qge02j5YIH98c0Ao0L7MmNDjU1GnNxQGZqwuMy/M0S7PUk1UeItV+Dbax4zxgL6qcu gmfL95pS3YJUdpnTZDpOoKErlpzLDIV3x/q8TL+vDXHeW1IlthS93tJkPgZNN11yzCkn 9PS22btv2OQVRc3/yGBVPmsZ0shyz6c/HoCVsk8gPXWWYO9frapqL+5QVprr+tA2ufzj GTp5AssMeUuda9/B7KK6h1fJBPVmfb9QLhg6c1QYD1JrCZJG1gcCh6US1J7nlN/ux146 AMJGouzrvUMIT7w3gj05y9pdJtqxuS8zn9AWliEhHIBjCT30mBMJLrLfEz3VXbnkpvLe EhPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778851493; x=1779456293; 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=kJkIJ9MSSyAx7AMR5IamH1iN68B4UTFJP9CxVTr4bw8=; b=d96jslfwyvLM91bkYn2qnmZDBHeCfpl3T1G6f0STgn9sCKKKQZqoC/XJjL/EngbyeT 8xWk+xQpfrs/h10Koqp9x3Qq9hRR7c/Wukvg6XnTIt2SLMBhMJWaeiHamgg0SWGsKG+J Obc/P5t1zXzCuOWVrFtBohZ/QjwXXZDxzXEY28gHFDPLF0m7XUABmB3M41Ki5ruIyK+s 6JuhQV/awuwCHUERUp/Qbi9BSIScDCxWDF7WzF++GcQEzuE2RSh6YQ4PV8NPqcpEkuW2 nKJA+uIVcbQLtQM/lcGEodDolODhXAX2A0HMqCXeMU1cqFEtEwQOJd+DFYTDkanqf1ZL V8nQ== X-Forwarded-Encrypted: i=1; AFNElJ/RUI9E/O3aTe8PrcUQ98olWh/1nl9wZd2Omp/0JXkdB4Wvh+yrG20I3iqxTw1Ya3RBKLgA/KJACuannbs=@vger.kernel.org X-Gm-Message-State: AOJu0Yy818gRuRYFJNfrWJEeegkHLwBoYKzuiR1CI7VeGpd1rdmxcbOt cHCVk+IA+5VaRPoAehA4URnf/jwqLKXgrbZDczuFMqF1mn6iWi6/yh/6bmpeUr8G3iU15I06Kj1 AHul6UUZ4cYQ8G9mZKBnCiPEE40J+2/eHpYEGeTax X-Gm-Gg: Acq92OGLUvvkfWm13JZqhUGPE3542OGTE6rWPlESMtd83lylZc4Ncwyxu2FivEKIj5r 0O8cBcT8sw+CbnZvLvXNCGMUJosu3+28BkD74H+BCtusISjUDW4AKhvera1tvKkyWb1VHjt5tRe 5YZdHWr3uzfpceM3CIBKgiIrr9/BNm1MzYlh5RpTEdO1Ac0y5KJcOVYeCe6R4uPBttkNQ5/LbKw s3plhEKAmJVwYK+80nQVg7oHtdX5AJ+zCSFIWIlit1e7DfVUfY8K2N451CDa0wEP08itkGt00Pk sNg5iV5fqBBy7bcdM0uT2G/AT+nD2jY+aN/k0brsT9yhtF3d X-Received: by 2002:a05:7022:62aa:b0:12a:72af:83d2 with SMTP id a92af1059eb24-1350441d7ccmr1656610c88.14.1778851492906; Fri, 15 May 2026 06:24:52 -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> <560a84ed-7daf-4a78-a314-b867c73bce22@kernel.org> In-Reply-To: <560a84ed-7daf-4a78-a314-b867c73bce22@kernel.org> From: Marco Elver Date: Fri, 15 May 2026 15:24:16 +0200 X-Gm-Features: AVHnY4IK86MdHMyPl5dB4zdZDdnYGN0oaLGQAymJ1xrwo4kBW5Idcq4vVdQ8Oeg Message-ID: Subject: Re: [PATCH v4 1/3] slab: support for compiler-assisted type-based slab cache partitioning To: "Vlastimil Babka (SUSE)" Cc: 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 , Harry Yoo , 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, GONG Ruiqi , Jonathan Corbet , "linux-doc@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" On Thu, 14 May 2026 at 11:01, Vlastimil Babka (SUSE) wrote: > > On 5/11/26 22:00, Marco Elver wrote: > > Rework the general infrastructure around RANDOM_KMALLOC_CACHES into more > > flexible KMALLOC_PARTITION_CACHES, with the former being a partitioning > > mode of the latter. > > > > Introduce a new mode, KMALLOC_PARTITION_TYPED, which leverages a feature > > available in Clang 22 and later, called "allocation tokens" via > > __builtin_infer_alloc_token() [1]. Unlike KMALLOC_PARTITION_RANDOM > > (formerly RANDOM_KMALLOC_CACHES), this mode deterministically assigns a > > slab cache to an allocation of type T, regardless of allocation site. > > > > The builtin __builtin_infer_alloc_token(, ...) instructs > > the compiler to infer an allocation type from arguments commonly passed > > to memory-allocating functions and returns a type-derived token ID. The > > implementation passes kmalloc-args to the builtin: the compiler performs > > best-effort type inference, and then recognizes common patterns such as > > `kmalloc(sizeof(T), ...)`, `kmalloc(sizeof(T) * n, ...)`, but also > > `(T *)kmalloc(...)`. Where the compiler fails to infer a type the > > fallback token (default: 0) is chosen. > > > > Note: kmalloc_obj(..) APIs fix the pattern how size and result type are > > expressed, and therefore ensures there's not much drift in which > > patterns the compiler needs to recognize. Specifically, kmalloc_obj() > > and friends expand to `(TYPE *)KMALLOC(__obj_size, GFP)`, which the > > compiler recognizes via the cast to TYPE*. > > > > Clang's default token ID calculation is described as [1]: > > > > typehashpointersplit: This mode assigns a token ID based on the hash > > of the allocated type's name, where the top half ID-space is reserved > > for types that contain pointers and the bottom half for types that do > > not contain pointers. > > > > Separating pointer-containing objects from pointerless objects and data > > allocations can help mitigate certain classes of memory corruption > > exploits [2]: attackers who gains a buffer overflow on a primitive > > buffer cannot use it to directly corrupt pointers or other critical > > metadata in an object residing in a different, isolated heap region. > > > > It is important to note that heap isolation strategies offer a > > best-effort approach, and do not provide a 100% security guarantee, > > albeit achievable at relatively low performance cost. Note that this > > also does not prevent cross-cache attacks: while waiting for future > > features like SLAB_VIRTUAL [3] to provide physical page isolation, this > > feature should be deployed alongside SHUFFLE_PAGE_ALLOCATOR and > > init_on_free=1 to mitigate cross-cache attacks and page-reuse attacks as > > much as possible today. > > > > With all that, my kernel (x86 defconfig) shows me a histogram of slab > > cache object distribution per /proc/slabinfo (after boot): > > > > > > kmalloc-part-15 1465 ++++++++++++++ > > kmalloc-part-14 2988 +++++++++++++++++++++++++++++ > > kmalloc-part-13 1656 ++++++++++++++++ > > kmalloc-part-12 1045 ++++++++++ > > kmalloc-part-11 1697 ++++++++++++++++ > > kmalloc-part-10 1489 ++++++++++++++ > > kmalloc-part-09 965 +++++++++ > > kmalloc-part-08 710 +++++++ > > kmalloc-part-07 100 + > > kmalloc-part-06 217 ++ > > kmalloc-part-05 105 + > > kmalloc-part-04 4047 ++++++++++++++++++++++++++++++++++++++++ > > kmalloc-part-03 183 + > > kmalloc-part-02 283 ++ > > kmalloc-part-01 316 +++ > > kmalloc 1422 ++++++++++++++ > > > > The above /proc/slabinfo snapshot shows me there are 6673 allocated > > objects (slabs 00 - 07) that the compiler claims contain no pointers or > > it was unable to infer the type of, and 12015 objects that contain > > pointers (slabs 08 - 15). On a whole, this looks relatively sane. > > > > Additionally, when I compile my kernel with -Rpass=alloc-token, which > > provides diagnostics where (after dead-code elimination) type inference > > failed, I see 186 allocation sites where the compiler failed to identify > > a type (down from 966 when I sent the RFC [4]). Some initial review > > confirms these are mostly variable sized buffers, but also include > > structs with trailing flexible length arrays. > > > > Link: https://clang.llvm.org/docs/AllocToken.html [1] > > Link: https://blog.dfsec.com/ios/2025/05/30/blasting-past-ios-18/ [2] > > Link: https://lwn.net/Articles/944647/ [3] > > Link: https://lore.kernel.org/all/20250825154505.1558444-1-elver@google.com/ [4] > > Link: https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434 > > Acked-by: GONG Ruiqi > > Co-developed-by: Harry Yoo (Oracle) > > Signed-off-by: Harry Yoo (Oracle) > > Signed-off-by: Marco Elver > > Applied [1] to slab/for-next, thanks. That means including the kernel-doc > workarounds in patch 3. I know Jon said someone might hate it, but maybe it > will motivate them for creating a proper fix :) It seems better than leaving > doc generation broken or not applying this series at all. Thanks! > https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git/log/?h=slab/for-7.2/alloc_token > > I did the following fixup to remove passing an unnecessary NULL argument for > __kmalloc_nolock() with buckets enabled. Made bloat-o-meter happier a bit. Good. > diff --git a/include/linux/slab.h b/include/linux/slab.h > index c232f8a10af6..795455256329 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -894,7 +894,7 @@ unsigned int kmem_cache_sheaf_size(struct slab_sheaf *sheaf); > * with the exception of kunit tests > */ > > -void *__kmalloc_noprof(DECL_KMALLOC_PARAMS(size, b, token), gfp_t flags) > +void *__kmalloc_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t flags) > __assume_kmalloc_alignment __alloc_size(1); > > void *__kmalloc_node_noprof(DECL_KMALLOC_PARAMS(size, b, token), gfp_t flags, int node) > @@ -981,7 +981,7 @@ static __always_inline __alloc_size(1) void *_kmalloc_noprof(size_t size, gfp_t > kmalloc_caches[kmalloc_type(flags, token)][index], > flags, size); > } > - return __kmalloc_noprof(PASS_KMALLOC_PARAMS(size, NULL, token), flags); > + return __kmalloc_noprof(PASS_TOKEN_PARAMS(size, token), flags); > } > #define kmalloc_noprof(...) _kmalloc_noprof(__VA_ARGS__, __kmalloc_token(__VA_ARGS__)) > #define kmalloc(...) alloc_hooks(kmalloc_noprof(__VA_ARGS__)) > diff --git a/mm/slub.c b/mm/slub.c > index a6e9015601d6..74652bbdd591 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -5303,10 +5303,10 @@ void *__kmalloc_node_noprof(DECL_KMALLOC_PARAMS(size, b, token), gfp_t flags, in > } > EXPORT_SYMBOL(__kmalloc_node_noprof); > > -void *__kmalloc_noprof(DECL_KMALLOC_PARAMS(size, b, token), gfp_t flags) > +void *__kmalloc_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t flags) > { > - return __do_kmalloc_node(size, PASS_BUCKET_PARAM(b), flags, > - NUMA_NO_NODE, _RET_IP_, PASS_TOKEN_PARAM(token)); > + return __do_kmalloc_node(size, NULL, flags, NUMA_NO_NODE, _RET_IP_, > + PASS_TOKEN_PARAM(token)); > } > EXPORT_SYMBOL(__kmalloc_noprof); Reviewed-by: Marco Elver Thanks!