From: "Harry Yoo (Oracle)" <harry@kernel.org>
To: Marco Elver <elver@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nsc@kernel.org>, Dennis Zhou <dennis@kernel.org>,
Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
Hao Li <hao.li@linux.dev>, David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Kees Cook <kees@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-hardening@vger.kernel.org,
kasan-dev@googlegroups.com, llvm@lists.linux.dev,
Andrey Konovalov <andreyknvl@gmail.com>,
Florent Revest <revest@google.com>,
GONG Ruiqi <gongruiqi@huaweicloud.com>,
Jann Horn <jannh@google.com>, KP Singh <kpsingh@kernel.org>,
Matteo Rizzo <matteorizzo@google.com>
Subject: Re: [PATCH v1] slab: support for compiler-assisted type-based slab cache partitioning
Date: Fri, 3 Apr 2026 15:28:26 +0900 [thread overview]
Message-ID: <ac9eCi0b33CYENpX@hyeyoo> (raw)
In-Reply-To: <20260331111240.153913-1-elver@google.com>
Now somewhat out-of-scope (or at least pre-existing) review comments
from Sashiko that I think are still worth mentioning...
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -662,9 +662,20 @@ extern kmem_buckets kmalloc_caches[NR_KMALLOC_TYPES];
> -static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags, unsigned long caller)
> +static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags, kmalloc_token_t token)
> {
> /*
> * The most common case is KMALLOC_NORMAL, so test for it
> @@ -672,9 +683,11 @@ static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags, unsigne
> */
> if (likely((flags & KMALLOC_NOT_NORMAL_BITS) == 0))
Sashiko pointed out KMALLOC_CGROUP caches are not partitioned [1]:
| Do allocations with the __GFP_ACCOUNT flag completely bypass typed
| and random partitioning? KMALLOC_NOT_NORMAL_BITS includes __GFP_ACCOUNT.
Right.
| If this bit is set, the code bypasses the partitioning logic and routes
| the allocation to the KMALLOC_CGROUP cache.
Right.
| Since user-controllable objects
| like msg_msg, file descriptors, and pipes are allocated with __GFP_ACCOUNT,
Right.
| they will all be clustered in the exact same unpartitioned cache.
Right.
From security perspective do you think it'd be worthwhile to partition
KMALLOC_CGROUP caches? (I see at least few hundreds of users, unlike
KMALLOC_RECLAIM where there are only few users).
Another valid concern from Sashiko [1]:
| Does this leave reallocation functions like krealloc() and kvrealloc()
| without allocation token propagation?
|
| When an object is reallocated and requires memory expansion, the underlying
| generic SLUB code allocates a new buffer. Because the token macro is not
| applied to these realloc paths, __builtin_infer_alloc_token() evaluates
| locally on a generic size_t variable rather than the original type.
I think this is a valid point and worth addressing.
| This causes it to return the fallback token (0), which silently migrates the
| object from its isolated typed cache to the shared fallback cache
| (kmalloc-part-00) when resized.
[1] https://sashiko.dev/#/patchset/20260331111240.153913-1-elver%40google.com
--
Cheers,
Harry / Hyeonggon
next prev parent reply other threads:[~2026-04-03 6:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 11:12 [PATCH v1] slab: support for compiler-assisted type-based slab cache partitioning Marco Elver
2026-04-02 6:24 ` kernel test robot
2026-04-02 13:33 ` Dan Carpenter
2026-04-02 13:48 ` Marco Elver
2026-04-02 17:05 ` Dan Carpenter
2026-04-02 19:08 ` Marco Elver
2026-04-03 6:27 ` Harry Yoo (Oracle)
2026-04-03 18:29 ` Vlastimil Babka (SUSE)
2026-04-06 4:28 ` Harry Yoo (Oracle)
2026-04-07 11:17 ` Marco Elver
2026-04-07 12:54 ` Harry Yoo (Oracle)
2026-04-09 20:19 ` Marco Elver
2026-04-10 2:10 ` Harry Yoo (Oracle)
2026-04-10 9:10 ` Marco Elver
2026-04-03 6:28 ` Harry Yoo (Oracle) [this message]
2026-04-10 9:50 ` GONG Ruiqi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ac9eCi0b33CYENpX@hyeyoo \
--to=harry@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=cl@gentwo.org \
--cc=david@kernel.org \
--cc=dennis@kernel.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=gongruiqi@huaweicloud.com \
--cc=gustavoars@kernel.org \
--cc=hao.li@linux.dev \
--cc=jannh@google.com \
--cc=justinstitt@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kees@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=llvm@lists.linux.dev \
--cc=matteorizzo@google.com \
--cc=mhocko@suse.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=nsc@kernel.org \
--cc=revest@google.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=tj@kernel.org \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.