[PATCH net-next v6 0/8] net: skb: isolate skb data area allocations into a separate bucket

[PATCH net-next v6 0/8] net: skb: isolate skb data area allocations into a separate bucket

[Kees Cook]

Hi!

This gets the buckets able to handle memcg (GFP_KERNEL_ACCOUNT) with
isolation (since it's common due to AF_UNIX), and GFP_DMA with fall back
(since it's rare). It gave me an excuse to build out bucket kunit tests
too, and that (and LLM review) found a couple other issues that needed
fixing too, including msg_msg allocations going uncharged to their memcg
when CONFIG_SLAB_BUCKETS=n (fixed in 2/8).

Harry, on your v4 question[1] about bucket users giving their own
alignment: I tried that in v5, but a set's allocations don't always
come from its own caches. With CONFIG_SLAB_BUCKETS=n, after a failed
kmem_buckets_create(), and for the DMA and reclaimable fallbacks, they
come from the general kmalloc caches, which can only give kmalloc()'s
alignment. So v6 goes back to mirroring the kmalloc cache's alignment,
and drops the ctor and flags arguments for the same reason. And the whole
exploration made me realize I had a completely wrong understanding of
how memcg worked. :P

The bulk of this is mm/slab, but the final patch is netdev, which Paolo
acked in v4, so I'm hoping this whole series can go via slab?

Thanks!

-Kees

 v6:
 - drop v5's 6/7 ("Let a bucket set handle __GFP_ACCOUNT") and its
   kmem_buckets_create_types(): memcg charges each object in whatever
   cache serves it, so accounted allocations can stay in a set's single
   row of caches, and the fallback now covers only DMA, reclaimable, and
   no-obj-ext allocations (Sashiko)
 - 2/8: new: account msg_msg with GFP_KERNEL_ACCOUNT again; with
   CONFIG_SLAB_BUCKETS=n it went uncharged, since its accounting lived in
   SLAB_ACCOUNT on bucket caches that are not created (Sashiko)
 - 3/8: new: drop the ctor and flags arguments from kmem_buckets_create();
   neither reaches allocations that fall back to the general kmalloc
   caches, and no caller needs them any more (Sashiko)
 - 4/8: go back to v4's form: no alignment argument, and each bucket cache
   takes the alignment of the kmalloc cache it mirrors, since the fallbacks
   to kmalloc can give no other (Sashiko, Harry)
 - 5/8: say in the teardown comment that cache sharing comes from kmalloc
   rounding sizes up to a larger class (Sashiko)
 - 6/8: drop the explicit alignment tests; check that each size lands in
   the cache of the size kmalloc() rounds it up to, not just a big enough
   one; and in the destroy test, assert on the allocation, skip when KFENCE
   serves it, and tear the set down through its KUnit cleanup action
   (Sashiko)
 - 7/8: keep __GFP_ACCOUNT allocations in the set, document what an
   allocation that falls back loses, and test the reclaimable fallback
   (Sashiko)
 - 8/8: create the skb_data set with kmem_buckets_create(), and make the
   comment above kmalloc_reserve() name no allocator (Sashiko)
 - v5..v6 diff: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/diff/?id=dev/v7.3-rc2/skb-buckets/v6&id2=dev/v7.3-rc2/skb-buckets/v5
 v5: https://lore.kernel.org/all/20261002231120.late.500-kees@kernel.org/
 v4: https://lore.kernel.org/all/20260921075811.too.775-kees@kernel.org/
 v3: https://lore.kernel.org/all/20260702170728.168755-1-pfalcato@suse.de/

[1] https://lore.kernel.org/all/arViR2Miz61-3fV4@thinkstation/

Kees Cook (7):
  mm/slab: Mark the kmem_buckets_create() context as a Context: section
  ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again
  mm/slab: Drop the ctor and flags arguments from kmem_buckets_create()
  mm/slab: Give bucket caches the alignment of the caches they mirror
  mm/slab: Add kmem_buckets_destroy()
  mm/slab: Add tests for the existing kmem_buckets behaviour
  mm/slab: Provide kmalloc type fallback for bucket allocations

Pedro Falcato (1):
  net: skb: isolate skb data area allocations into a separate bucket

 include/linux/slab.h   |   6 +-
 mm/slab.h              |  19 ++-
 ipc/msgutil.c          |   8 +-
 lib/tests/slub_kunit.c | 291 +++++++++++++++++++++++++++++++++++++++++
 mm/slab_common.c       |  74 ++++++++---
 mm/util.c              |   2 +-
 net/core/skbuff.c      |  10 +-
 7 files changed, 378 insertions(+), 32 deletions(-)

-- 
2.55.0

[PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Kees Cook]

Since commit 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for
alloc_msg()"), alloc_msg() allocates with GFP_KERNEL, and a msg_msg is
accounted only through SLAB_ACCOUNT on its bucket caches. With
CONFIG_SLAB_BUCKETS=n, kmem_buckets_create() creates no caches and
kmem_buckets_alloc() is a GFP_KERNEL kmalloc() from the general caches,
which do not account it; the same happens when kmem_buckets_create()
fails. Either way, the allocation is not charged to the sender's memory
cgroup.

Allocate with GFP_KERNEL_ACCOUNT again, as before that commit. Memcg
charges such an allocation in whichever cache serves it, so drop the
SLAB_ACCOUNT, which no longer adds anything.

Build tested ARCH=x86_64 defconfig with GCC 16.2.0, with
CONFIG_SLAB_BUCKETS as y and n.

Fixes: 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for alloc_msg()")
Assisted-by: LLM
Signed-off-by: Kees Cook <kees@kernel.org>
---
 ipc/msgutil.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ipc/msgutil.c b/ipc/msgutil.c
index e28f0cecb2ec..1ba8e59cb255 100644
--- a/ipc/msgutil.c
+++ b/ipc/msgutil.c
@@ -43,7 +43,7 @@ static kmem_buckets *msg_buckets __ro_after_init;
 
 static int __init init_msg_buckets(void)
 {
-	msg_buckets = kmem_buckets_create("msg_msg", SLAB_ACCOUNT,
+	msg_buckets = kmem_buckets_create("msg_msg", 0,
 					  sizeof(struct msg_msg),
 					  DATALEN_MSG, NULL);
 
@@ -58,7 +58,8 @@ static struct msg_msg *alloc_msg(size_t len)
 	size_t alen;
 
 	alen = min(len, DATALEN_MSG);
-	msg = kmem_buckets_alloc(msg_buckets, sizeof(*msg) + alen, GFP_KERNEL);
+	msg = kmem_buckets_alloc(msg_buckets, sizeof(*msg) + alen,
+				 GFP_KERNEL_ACCOUNT);
 	if (msg == NULL)
 		return NULL;
 
-- 
2.55.0

[PATCH net-next v6 7/8] mm/slab: Provide kmalloc type fallback for bucket allocations

[Kees Cook]

kmem_buckets_create() clones kmalloc_caches[KMALLOC_NORMAL].
kmalloc_slab() figures out the kmalloc type the caller asks for, but
then ignored it whenever a bucket set was in use, returning a normal
cache regardless. That breaks an allocation that needs other pages: a
GFP_DMA allocation would not get memory from ZONE_DMA, and a
__GFP_RECLAIMABLE one would miss the reclaimable caches. None of the
current users do this, so there is no problem, but it makes adding new
users fragile. For example, skb data[1] needs to handle GFP_DMA (rarely).

Send those allocations to the general caches instead, so nothing breaks
and regular allocations remain isolated in the set. Accounted
allocations stay in the set: memcg charges each object on its own, in
any cache, so a bucket cache serves them as well as kmalloc-cg-* does.

Built and tests pass with ARCH=x86_64 defconfig with GCC 16.2.0, with
CONFIG_SLAB_BUCKETS as y and n, and with CONFIG_MEMCG as y, n, and y
with "cgroup.memory=nokmem".

Assisted-by: LLM
Link: https://lore.kernel.org/all/04debe19-bbe8-4b5f-9668-753d1f97832d@redhat.com/ [1]
Signed-off-by: Kees Cook <kees@kernel.org>
---
 mm/slab.h              | 19 +++++++++++--
 lib/tests/slub_kunit.c | 63 ++++++++++++++++++++++++++++++++++++++++++
 mm/slab_common.c       |  5 ++++
 3 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/mm/slab.h b/mm/slab.h
index 8fd6835e4235..af39a4e47c9e 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -421,6 +421,22 @@ static inline unsigned int size_index_elem(unsigned int bytes)
 	return (bytes - 1) / 8;
 }
 
+/*
+ * Which set of buckets to use for the given kmalloc_cache_type. A bucket set
+ * mirrors the KMALLOC_NORMAL caches, and also serves accounted allocations:
+ * memcg charges each object on its own, in any cache. Types that need
+ * different pages (DMA, reclaimable) or no obj_exts fall back to the
+ * general caches.
+ */
+static inline kmem_buckets *
+kmalloc_choose_bucket(kmem_buckets *bucket, enum kmalloc_cache_type type)
+{
+	if (bucket && (type <= KMALLOC_PARTITION_END || type == KMALLOC_CGROUP))
+		return bucket;
+
+	return &kmalloc_caches[type];
+}
+
 /*
  * Find the kmem_cache structure that serves a given size of
  * allocation
@@ -438,8 +454,7 @@ kmalloc_slab(size_t size, kmem_buckets *b, gfp_t flags, kmalloc_token_t token,
 	if (alloc_flags & SLAB_ALLOC_NO_OBJ_EXT)
 		type = KMALLOC_NO_OBJ_EXT;
 
-	if (!b)
-		b = &kmalloc_caches[type];
+	b = kmalloc_choose_bucket(b, type);
 	if (size <= 192)
 		index = kmalloc_size_index[size_index_elem(size)];
 	else
diff --git a/lib/tests/slub_kunit.c b/lib/tests/slub_kunit.c
index a2a15a49c5d7..1e6fcbbf8409 100644
--- a/lib/tests/slub_kunit.c
+++ b/lib/tests/slub_kunit.c
@@ -697,6 +697,68 @@ static void test_kmem_buckets_destroy(struct kunit *test)
 	KUNIT_EXPECT_EQ(test, 2, slab_errors);
 }
 
+/*
+ * A bucket set mirrors the normal kmalloc caches, which can serve accounted
+ * allocations too, so those stay in the set. An allocation that needs other
+ * pages (DMA or reclaimable) has to come from the general caches. Check that
+ * it does, rather than being served a cache that does not satisfy what the
+ * flags asked for.
+ */
+static void test_kmem_buckets_type_fallback(struct kunit *test)
+{
+	struct kmem_cache *c;
+	kmem_buckets *b;
+	void *p;
+
+	if (!IS_ENABLED(CONFIG_SLAB_BUCKETS))
+		kunit_skip(test, "needs CONFIG_SLAB_BUCKETS");
+
+	b = kmem_buckets_create("test_buckets", 0, INT_MAX);
+	KUNIT_ASSERT_BUCKETS_CREATED(test, b);
+
+	/* A plain allocation stays isolated in the bucket set. */
+	p = kmem_buckets_alloc(b, 128, GFP_KERNEL);
+	KUNIT_ASSERT_NOT_NULL(test, p);
+	c = cache_of(p);
+	kfree(p);
+	KUNIT_ASSERT_NOT_NULL(test, c);
+
+	KUNIT_EXPECT_TRUE_MSG(test, strstarts(c->name, "test_buckets-"),
+			      "expected a bucket cache, got %s", c->name);
+
+	/* One that needs ZONE_DMA cannot, so it falls back. */
+	if (IS_ENABLED(CONFIG_ZONE_DMA)) {
+		p = kmem_buckets_alloc(b, 128, GFP_KERNEL | GFP_DMA);
+		KUNIT_ASSERT_NOT_NULL(test, p);
+		c = cache_of(p);
+		kfree(p);
+		KUNIT_ASSERT_NOT_NULL(test, c);
+
+		KUNIT_EXPECT_TRUE_MSG(test, strstarts(c->name, "dma-kmalloc-"),
+				      "expected a DMA cache, got %s", c->name);
+	}
+
+	/* Nor can one that is reclaimable. */
+	p = kmem_buckets_alloc(b, 128, GFP_KERNEL | __GFP_RECLAIMABLE);
+	KUNIT_ASSERT_NOT_NULL(test, p);
+	c = cache_of(p);
+	kfree(p);
+	KUNIT_ASSERT_NOT_NULL(test, c);
+
+	KUNIT_EXPECT_TRUE_MSG(test, strstarts(c->name, "kmalloc-rcl-"),
+			      "expected a reclaimable cache, got %s", c->name);
+
+	/* An accounted allocation stays in the set; memcg charges it there. */
+	p = kmem_buckets_alloc(b, 128, GFP_KERNEL | __GFP_ACCOUNT);
+	KUNIT_ASSERT_NOT_NULL(test, p);
+	c = cache_of(p);
+	kfree(p);
+	KUNIT_ASSERT_NOT_NULL(test, c);
+
+	KUNIT_EXPECT_TRUE_MSG(test, strstarts(c->name, "test_buckets-"),
+			      "expected a bucket cache, got %s", c->name);
+}
+
 static struct kunit_case test_cases[] = {
 	KUNIT_CASE(test_clobber_zone),
 
@@ -723,6 +785,7 @@ static struct kunit_case test_cases[] = {
 	KUNIT_CASE(test_kmem_buckets_alignment),
 	KUNIT_CASE(test_kmem_buckets_disabled),
 	KUNIT_CASE(test_kmem_buckets_destroy),
+	KUNIT_CASE(test_kmem_buckets_type_fallback),
 	{}
 };
 
diff --git a/mm/slab_common.c b/mm/slab_common.c
index fb1dd15953a7..6fa02b4ff775 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -420,6 +420,11 @@ static struct kmem_cache *kmem_buckets_cache __ro_after_init;
  * @usersize: How many bytes, starting at @useroffset, may be copied
  *		to/from userspace.
  *
+ * Accounted (__GFP_ACCOUNT) allocations are served by the set like any
+ * other. Allocations that need DMA or reclaimable memory are served by the
+ * general kmalloc caches instead, without the set's isolation or usercopy
+ * region.
+ *
  * Context: Cannot be called within an interrupt, but can be interrupted.
  *
  * Return: a pointer to the cache on success, NULL on failure. When
-- 
2.55.0

Re: [PATCH net-next v6 0/8] net: skb: isolate skb data area allocations into a separate bucket

[Harry Yoo]

On Tue, Oct 06, 2026 at 02:20:26AM -0700, Kees Cook wrote:
> Hi!

Hi Kees!

Was hoping to say hi to you at LPC but I missed the chance ;)
Maybe next time. Safe travels!

Uh, my mailbox stopped working for a few days as I forgot to renew
subscription. (Kiryl told me it's bouncing, thanks!) Hopefully I didn't
miss too much...

> This gets the buckets able to handle memcg (GFP_KERNEL_ACCOUNT) with
> isolation (since it's common due to AF_UNIX),

Cool!

> and GFP_DMA with fall back
> (since it's rare).

> It gave me an excuse to build out bucket kunit tests
> too, and that (and LLM review) found a couple other issues that needed
> fixing too, including msg_msg allocations going uncharged to their memcg
> when CONFIG_SLAB_BUCKETS=n (fixed in 2/8).

Oh.

> Harry, on your v4 question[1] about bucket users giving their own
> alignment: I tried that in v5, but a set's allocations don't always
> come from its own caches. With CONFIG_SLAB_BUCKETS=n, after a failed
> kmem_buckets_create(), and for the DMA and reclaimable fallbacks, they
> come from the general kmalloc caches, which can only give kmalloc()'s
> alignment.
>
> So v6 goes back to mirroring the kmalloc cache's alignment,

I might be missing something, but why is that a problem?

For kmem_buckets users, the reason* to specify alignment is because
they might need less strict alignment than kmalloc.

(*Perhaps it's nice to document that in the comment)

However, because kmem_buckets can fall back to kmalloc on e.g. kernels
w/o CONFIG_SLAB_BUCKETS, it should be fine to fall back. No?

Creating kmem_buckets with more strict alignment than
kmalloc doesn't make sense. 

> and drops the ctor and flags arguments for the same reason.

Uh, for ctor and flags, yes. We can't have them in kmem_buckets.

> And the whole
> exploration made me realize I had a completely wrong understanding of
> how memcg worked. :P
> 
> The bulk of this is mm/slab, but the final patch is netdev, which Paolo
> acked in v4, so I'm hoping this whole series can go via slab?

Going thorough slab/for-next sounds reasonable to me once it gets
some reviews.

Vlastimil?

-- 
Cheers,
Harry / Hyeonggon

Re: [PATCH net-next v6 0/8] net: skb: isolate skb data area allocations into a separate bucket

[Kees Cook]

On Thu, Oct 08, 2026 at 11:25:13PM +0200, Harry Yoo wrote:
> On Tue, Oct 06, 2026 at 02:20:26AM -0700, Kees Cook wrote:
> > Hi!
> 
> Hi Kees!
> 
> Was hoping to say hi to you at LPC but I missed the chance ;)
> Maybe next time. Safe travels!

Hi! Yes, I kept trying to find you and Vlastimil but it never worked out.
LPC is a non-stop hallway track usually. :) I will try again next year!

> > So v6 goes back to mirroring the kmalloc cache's alignment,
> 
> I might be missing something, but why is that a problem?
> 
> For kmem_buckets users, the reason* to specify alignment is because
> they might need less strict alignment than kmalloc.
> 
> (*Perhaps it's nice to document that in the comment)
> 
> However, because kmem_buckets can fall back to kmalloc on e.g. kernels
> w/o CONFIG_SLAB_BUCKETS, it should be fine to fall back. No?
> 
> Creating kmem_buckets with more strict alignment than
> kmalloc doesn't make sense. 
> 
> > and drops the ctor and flags arguments for the same reason.
> 
> Uh, for ctor and flags, yes. We can't have them in kmem_buckets.

Yeah, and given that these two, I'd just prefer to keep it a direct
mirror for alignment too and not allow for any configurability here:
they are supposed to be direct stand-ins for the general cache.

> Going thorough slab/for-next sounds reasonable to me once it gets
> some reviews.

Thanks!

-Kees

-- 
Kees Cook

Re: [PATCH net-next v6 0/8] net: skb: isolate skb data area allocations into a separate bucket

[Vlastimil Babka]

On October 8, 2026 11:25:13 PM GMT+02:00, Harry Yoo <harry@kernel.org> wrote:
>On Tue, Oct 06, 2026 at 02:20:26AM -0700, Kees Cook wrote:
>> Hi!
>
>Hi Kees!
>
>Was hoping to say hi to you at LPC but I missed the chance ;)
>Maybe next time. Safe travels!
>
>Uh, my mailbox stopped working for a few days as I forgot to renew
>subscription. (Kiryl told me it's bouncing, thanks!) Hopefully I didn't
>miss too much...
>
>> This gets the buckets able to handle memcg (GFP_KERNEL_ACCOUNT) with
>> isolation (since it's common due to AF_UNIX),
>
>Cool!
>
>> and GFP_DMA with fall back
>> (since it's rare).
>
>> It gave me an excuse to build out bucket kunit tests
>> too, and that (and LLM review) found a couple other issues that needed
>> fixing too, including msg_msg allocations going uncharged to their memcg
>> when CONFIG_SLAB_BUCKETS=n (fixed in 2/8).
>
>Oh.
>
>> Harry, on your v4 question[1] about bucket users giving their own
>> alignment: I tried that in v5, but a set's allocations don't always
>> come from its own caches. With CONFIG_SLAB_BUCKETS=n, after a failed
>> kmem_buckets_create(), and for the DMA and reclaimable fallbacks, they
>> come from the general kmalloc caches, which can only give kmalloc()'s
>> alignment.
>>
>> So v6 goes back to mirroring the kmalloc cache's alignment,
>
>I might be missing something, but why is that a problem?
>
>For kmem_buckets users, the reason* to specify alignment is because
>they might need less strict alignment than kmalloc.
>
>(*Perhaps it's nice to document that in the comment)
>
>However, because kmem_buckets can fall back to kmalloc on e.g. kernels
>w/o CONFIG_SLAB_BUCKETS, it should be fine to fall back. No?
>
>Creating kmem_buckets with more strict alignment than
>kmalloc doesn't make sense. 
>
>> and drops the ctor and flags arguments for the same reason.
>
>Uh, for ctor and flags, yes. We can't have them in kmem_buckets.
>
>> And the whole
>> exploration made me realize I had a completely wrong understanding of
>> how memcg worked. :P
>> 
>> The bulk of this is mm/slab, but the final patch is netdev, which Paolo
>> acked in v4, so I'm hoping this whole series can go via slab?
>
>Going thorough slab/for-next sounds reasonable to me once it gets
>some reviews.
>
>Vlastimil?

Sure! If you review and feel it's ready to be added there, please do so. I couldn't yet due to conferencing, should be able next week.

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Harry Yoo]

On Tue, Oct 06, 2026 at 02:20:28AM -0700, Kees Cook wrote:
> Since commit 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for
> alloc_msg()"), alloc_msg() allocates with GFP_KERNEL, and a msg_msg is
> accounted only through SLAB_ACCOUNT on its bucket caches.

> With
> CONFIG_SLAB_BUCKETS=n, kmem_buckets_create() creates no caches and
> kmem_buckets_alloc() is a GFP_KERNEL kmalloc() from the general caches,
> which do not account it; the same happens when kmem_buckets_create()
> fails. Either way, the allocation is not charged to the sender's memory
> cgroup.

Ouch, now I see what's gone wrong here... 
The fix for this bug should be Cc: stable IMHO.
Allowing to escape memcg charging is not good.

> Allocate with GFP_KERNEL_ACCOUNT again, as before that commit. Memcg
> charges such an allocation in whichever cache serves it, so drop the
> SLAB_ACCOUNT, which no longer adds anything.

Hmm in the long term we don't want allowing __GFP_ACCOUNT allocations
that are served from slab caches without SLAB_ACCOUNT, as this wastes
memory.

See: https://lore.kernel.org/linux-mm/20260720-b4-objext_split-v2-0-2fa7c6f60dbe@kernel.org

And now I see the initial kmem_buckets design did not sufficiently
tackle the question "How this should work when kmem_buckets falls back
to kmalloc?"

I suppose the kmem_buckets' abstraction should not be too tightly
coupled with kmalloc caches. Creating a kmem_buckets should be
conceptually equivalent to creating a set of caches with speicifc
slab flags, size, align, useroffset/size. (for variable size allocation).

When it falls back to kmalloc, kmem_buckets itself should provide a
compatibility layer when falling back to kmalloc.
(Okay, allowing ctor is completely broken, but other attributes are fine)

...I don't agree with the idea that "since kmem_buckets can fall back to
kmalloc, kmem_buckets can only have the same requirements as kmalloc
(slab flags, alignment, etc.)".

By that logic, shouldn't we give up specifying useroffset and usersize
too? :-)

> Build tested ARCH=x86_64 defconfig with GCC 16.2.0, with
> CONFIG_SLAB_BUCKETS as y and n.
> 
> Fixes: 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for alloc_msg()")
>
> Assisted-by: LLM
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
>  ipc/msgutil.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/ipc/msgutil.c b/ipc/msgutil.c
> index e28f0cecb2ec..1ba8e59cb255 100644
> --- a/ipc/msgutil.c
> +++ b/ipc/msgutil.c
> @@ -43,7 +43,7 @@ static kmem_buckets *msg_buckets __ro_after_init;
>  
>  static int __init init_msg_buckets(void)
>  {
> -	msg_buckets = kmem_buckets_create("msg_msg", SLAB_ACCOUNT,
> +	msg_buckets = kmem_buckets_create("msg_msg", 0,
>  					  sizeof(struct msg_msg),
>  					  DATALEN_MSG, NULL);
>  
> @@ -58,7 +58,8 @@ static struct msg_msg *alloc_msg(size_t len)
>  	size_t alen;
>  
>  	alen = min(len, DATALEN_MSG);
> -	msg = kmem_buckets_alloc(msg_buckets, sizeof(*msg) + alen, GFP_KERNEL);
> +	msg = kmem_buckets_alloc(msg_buckets, sizeof(*msg) + alen,
> +				 GFP_KERNEL_ACCOUNT);
>  	if (msg == NULL)
>  		return NULL;

-- 
Cheers,
Harry / Hyeonggon

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Harry Yoo]

On Fri, Oct 09, 2026 at 04:22:03PM +0200, Harry Yoo wrote:
> And now I see the initial kmem_buckets design did not sufficiently
> tackle the question "How this should work when kmem_buckets falls back
> to kmalloc?"
> 
> I suppose the kmem_buckets' abstraction should not be too tightly
> coupled with kmalloc caches. Creating a kmem_buckets should be
> conceptually equivalent to creating a set of caches with speicifc
> slab flags, size, align, useroffset/size. (for variable size allocation).

Just to clarify... I have a few concerns on this area.

1. Complexity.

It's very counter-intuitive to understand how it works when
SLAB_BUCKETS is not compiled. My brain cannot easily process two
different implementations w/ and w/o SLAB_BUCKETS.

A "compatibility layer" allows us to assume certain expectations
and ignore all implementation details when SLAB_BUCKETS is not compiled.

2. Making kmem_buckets tightly coupled with kmalloc's implementation
   details is not reasonable.

Let's say, at some point we make SLAB_BUCKETS always enabled and drop
the config option. Then all kmem_buckets users will now have certain
assumptions inherted from kmalloc (e.g. alignment), which is not
reasonable.

3. __GFP_ACCOUNT and __GFP_DMA should be applied to all allocations
in the slab cache. For kmalloc, these flags are only used to select
the kmalloc cache (which has equivalent SLAB_* flags for __GFP_ACCOUNT
or __GFP_DMA) to serve the allocation.

Specifying it on individual allocations (rather than as SLAB_ flags)
makes it easy to break the assumption.

> When it falls back to kmalloc, kmem_buckets itself should provide a
> compatibility layer when falling back to kmalloc.

For example, calculate_sizes() converts certain SLAB_* flags into
GFP flags (s->allocflags) for allocation. We can have a similar
logic when falling back to kmalloc.

Though current implementation does not allow this and requires
some rework.

-- 
Cheers,
Harry / Hyeonggon

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Kees Cook]

On Fri, Oct 09, 2026 at 04:22:01PM +0200, Harry Yoo wrote:
> On Tue, Oct 06, 2026 at 02:20:28AM -0700, Kees Cook wrote:
> > Since commit 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for
> > alloc_msg()"), alloc_msg() allocates with GFP_KERNEL, and a msg_msg is
> > accounted only through SLAB_ACCOUNT on its bucket caches.
> 
> > With
> > CONFIG_SLAB_BUCKETS=n, kmem_buckets_create() creates no caches and
> > kmem_buckets_alloc() is a GFP_KERNEL kmalloc() from the general caches,
> > which do not account it; the same happens when kmem_buckets_create()
> > fails. Either way, the allocation is not charged to the sender's memory
> > cgroup.
> 
> Ouch, now I see what's gone wrong here... 
> The fix for this bug should be Cc: stable IMHO.
> Allowing to escape memcg charging is not good.

Anything with Fixes: will end up in stable, so I just leave off the
stable CC these days.

> > Allocate with GFP_KERNEL_ACCOUNT again, as before that commit. Memcg
> > charges such an allocation in whichever cache serves it, so drop the
> > SLAB_ACCOUNT, which no longer adds anything.
> 
> Hmm in the long term we don't want allowing __GFP_ACCOUNT allocations
> that are served from slab caches without SLAB_ACCOUNT, as this wastes
> memory.
> 
> See: https://lore.kernel.org/linux-mm/20260720-b4-objext_split-v2-0-2fa7c6f60dbe@kernel.org

This is how I thought things worked, so my original version of this
series kept separate caches. (I can return to that too, but it doesn't
seem to be needed today?)

> And now I see the initial kmem_buckets design did not sufficiently
> tackle the question "How this should work when kmem_buckets falls back
> to kmalloc?"

Right. We could just make kmem_buckets non-optional, too? Then they
could have all the caller personalization they need.

> I suppose the kmem_buckets' abstraction should not be too tightly
> coupled with kmalloc caches. Creating a kmem_buckets should be
> conceptually equivalent to creating a set of caches with speicifc
> slab flags, size, align, useroffset/size. (for variable size allocation).

In my mind, the general kmalloc caches are just a specific instance of a
kmem_buckets...

> When it falls back to kmalloc, kmem_buckets itself should provide a
> compatibility layer when falling back to kmalloc.

IMO, it'd just be better to make kmem_buckets not NEED a compat layer...

> (Okay, allowing ctor is completely broken, but other attributes are fine)
> 
> ...I don't agree with the idea that "since kmem_buckets can fall back to
> kmalloc, kmem_buckets can only have the same requirements as kmalloc
> (slab flags, alignment, etc.)".
> 
> By that logic, shouldn't we give up specifying useroffset and usersize
> too? :-)

Yup, but I kept that since only the hardening guarantees change under
that condition -- nothing operationally depends on useroffset/size.

-Kees

-- 
Kees Cook

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Kees Cook]

On Fri, Oct 09, 2026 at 09:39:48PM +0200, Harry Yoo wrote:
> On Fri, Oct 09, 2026 at 04:22:03PM +0200, Harry Yoo wrote:
> > And now I see the initial kmem_buckets design did not sufficiently
> > tackle the question "How this should work when kmem_buckets falls back
> > to kmalloc?"
> > 
> > I suppose the kmem_buckets' abstraction should not be too tightly
> > coupled with kmalloc caches. Creating a kmem_buckets should be
> > conceptually equivalent to creating a set of caches with speicifc
> > slab flags, size, align, useroffset/size. (for variable size allocation).
> 
> Just to clarify... I have a few concerns on this area.
> 
> 1. Complexity.
> 
> It's very counter-intuitive to understand how it works when
> SLAB_BUCKETS is not compiled. My brain cannot easily process two
> different implementations w/ and w/o SLAB_BUCKETS.
> 
> A "compatibility layer" allows us to assume certain expectations
> and ignore all implementation details when SLAB_BUCKETS is not compiled.

I'd rather make kmem_buckets not have a SLAB_BUCKETS option. :)

> 2. Making kmem_buckets tightly coupled with kmalloc's implementation
>    details is not reasonable.
> 
> Let's say, at some point we make SLAB_BUCKETS always enabled and drop
> the config option. Then all kmem_buckets users will now have certain
> assumptions inherted from kmalloc (e.g. alignment), which is not
> reasonable.

Until it's always enabled, I don't see a reasonable way to separate
those assumptions.

> 3. __GFP_ACCOUNT and __GFP_DMA should be applied to all allocations
> in the slab cache. For kmalloc, these flags are only used to select
> the kmalloc cache (which has equivalent SLAB_* flags for __GFP_ACCOUNT
> or __GFP_DMA) to serve the allocation.
> 
> Specifying it on individual allocations (rather than as SLAB_ flags)
> makes it easy to break the assumption.

As in, you don't want a "pass-through" mode for __GFP_DMA?

It's a lot of overhead for __GFP_DMA to have multiple providers, so I'd
rather allow kmem_buckets to allow pass-through (perhaps explicitly
opt-in) where then the other options (e.g. alignment) must match the
general kmalloc caches so that pass-through is consistent.

> > When it falls back to kmalloc, kmem_buckets itself should provide a
> > compatibility layer when falling back to kmalloc.
> 
> For example, calculate_sizes() converts certain SLAB_* flags into
> GFP flags (s->allocflags) for allocation. We can have a similar
> logic when falling back to kmalloc.
> 
> Though current implementation does not allow this and requires
> some rework.

I think the current series does everything correctly in the sense that
nothing is allowing for mismatched fallbacks/passthrus. We could iterate
from there once we have a need for this where a non-kmalloc-alignment is
wanted, etc?

-- 
Kees Cook

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Andrew Morton]

On Fri, 9 Oct 2026 20:14:20 -0700 Kees Cook <kees@kernel.org> wrote:

> Anything with Fixes: will end up in stable, so I just leave off the
> stable CC these days.

-stable maintainers have been asked to Not Do That for mm patches. 
Other subsystems are doing the same.

I don't know how they determine whether something is an mm patch.  A
patch which covers do-do-that and dont-do-that parts of the tree is
likely to be mishandled.

So yeah, add that cc:stable to reduce the possibility of mistakes.

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Vlastimil Babka (SUSE)]

On 10/11/26 00:37, Andrew Morton wrote:
> On Fri, 9 Oct 2026 20:14:20 -0700 Kees Cook <kees@kernel.org> wrote:
> 
>> Anything with Fixes: will end up in stable, so I just leave off the
>> stable CC these days.
> 
> -stable maintainers have been asked to Not Do That for mm patches. 
> Other subsystems are doing the same.
> 
> I don't know how they determine whether something is an mm patch.  A
> patch which covers do-do-that and dont-do-that parts of the tree is
> likely to be mishandled.
> 
> So yeah, add that cc:stable to reduce the possibility of mistakes.

There's also this from the list of pain points at
https://lwn.net/Articles/1099594/

    Kroah-Hartman: subsystems that do not add CC: stable@vger.kernel.org
tags to patches, but which still expect the stable team to pick up the
important fixes anyway. The stable maintainers are overwhelmed as it is and
are not doing that.

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Vlastimil Babka (SUSE)]

On 10/6/26 11:20, Kees Cook wrote:
> Since commit 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for
> alloc_msg()"), alloc_msg() allocates with GFP_KERNEL, and a msg_msg is
> accounted only through SLAB_ACCOUNT on its bucket caches. With
> CONFIG_SLAB_BUCKETS=n, kmem_buckets_create() creates no caches and
> kmem_buckets_alloc() is a GFP_KERNEL kmalloc() from the general caches,
> which do not account it; the same happens when kmem_buckets_create()
> fails. Either way, the allocation is not charged to the sender's memory
> cgroup.
> 
> Allocate with GFP_KERNEL_ACCOUNT again, as before that commit. Memcg
> charges such an allocation in whichever cache serves it, so drop the
> SLAB_ACCOUNT, which no longer adds anything.
> 
> Build tested ARCH=x86_64 defconfig with GCC 16.2.0, with
> CONFIG_SLAB_BUCKETS as y and n.
> 
> Fixes: 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for alloc_msg()")
> Assisted-by: LLM
> Signed-off-by: Kees Cook <kees@kernel.org>

Could we, for the purposes of a backportable fix, just have both
SLAB_ACCOUNT and GFP_KERNEL_ACCOUNT in place? That should do the right thing
regardless of CONFIG_SLAB_BUCKETS state, no?

> ---
>  ipc/msgutil.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/ipc/msgutil.c b/ipc/msgutil.c
> index e28f0cecb2ec..1ba8e59cb255 100644
> --- a/ipc/msgutil.c
> +++ b/ipc/msgutil.c
> @@ -43,7 +43,7 @@ static kmem_buckets *msg_buckets __ro_after_init;
>  
>  static int __init init_msg_buckets(void)
>  {
> -	msg_buckets = kmem_buckets_create("msg_msg", SLAB_ACCOUNT,
> +	msg_buckets = kmem_buckets_create("msg_msg", 0,
>  					  sizeof(struct msg_msg),
>  					  DATALEN_MSG, NULL);
>  
> @@ -58,7 +58,8 @@ static struct msg_msg *alloc_msg(size_t len)
>  	size_t alen;
>  
>  	alen = min(len, DATALEN_MSG);
> -	msg = kmem_buckets_alloc(msg_buckets, sizeof(*msg) + alen, GFP_KERNEL);
> +	msg = kmem_buckets_alloc(msg_buckets, sizeof(*msg) + alen,
> +				 GFP_KERNEL_ACCOUNT);
>  	if (msg == NULL)
>  		return NULL;
>  

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Vlastimil Babka (SUSE)]

On 10/12/26 19:55, Vlastimil Babka (SUSE) wrote:
> On 10/6/26 11:20, Kees Cook wrote:
>> Since commit 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for
>> alloc_msg()"), alloc_msg() allocates with GFP_KERNEL, and a msg_msg is
>> accounted only through SLAB_ACCOUNT on its bucket caches. With
>> CONFIG_SLAB_BUCKETS=n, kmem_buckets_create() creates no caches and
>> kmem_buckets_alloc() is a GFP_KERNEL kmalloc() from the general caches,
>> which do not account it; the same happens when kmem_buckets_create()
>> fails. Either way, the allocation is not charged to the sender's memory
>> cgroup.
>> 
>> Allocate with GFP_KERNEL_ACCOUNT again, as before that commit. Memcg
>> charges such an allocation in whichever cache serves it, so drop the
>> SLAB_ACCOUNT, which no longer adds anything.
>> 
>> Build tested ARCH=x86_64 defconfig with GCC 16.2.0, with
>> CONFIG_SLAB_BUCKETS as y and n.
>> 
>> Fixes: 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for alloc_msg()")
>> Assisted-by: LLM
>> Signed-off-by: Kees Cook <kees@kernel.org>
> 
> Could we, for the purposes of a backportable fix, just have both
> SLAB_ACCOUNT and GFP_KERNEL_ACCOUNT in place? That should do the right thing
> regardless of CONFIG_SLAB_BUCKETS state, no?

BTW we're thinking to add 1+2 (once this part is clarified) for 7.4 (with
stable@ for patch 2). But for the rest we'll have to target 7.5 as it's only
a week to the 7.4 merge window now.

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Harry Yoo]

On Fri, Oct 09, 2026 at 08:18:59PM -0700, Kees Cook wrote:
> On Fri, Oct 09, 2026 at 09:39:48PM +0200, Harry Yoo wrote:
> > On Fri, Oct 09, 2026 at 04:22:03PM +0200, Harry Yoo wrote:
> > > And now I see the initial kmem_buckets design did not sufficiently
> > > tackle the question "How this should work when kmem_buckets falls back
> > > to kmalloc?"
> > > 
> > > I suppose the kmem_buckets' abstraction should not be too tightly
> > > coupled with kmalloc caches. Creating a kmem_buckets should be
> > > conceptually equivalent to creating a set of caches with speicifc
> > > slab flags, size, align, useroffset/size. (for variable size allocation).
> > 
> > Just to clarify... I have a few concerns on this area.
> > 
> > 1. Complexity.
> > 
> > It's very counter-intuitive to understand how it works when
> > SLAB_BUCKETS is not compiled. My brain cannot easily process two
> > different implementations w/ and w/o SLAB_BUCKETS.
> > 
> > A "compatibility layer" allows us to assume certain expectations
> > and ignore all implementation details when SLAB_BUCKETS is not compiled.
> 
> I'd rather make kmem_buckets not have a SLAB_BUCKETS option. :)

We'll need some data but looking at the discussion thread [1]:
> I wasn't able to measure any performance impact at all. It does add a
> small bit of memory overhead, but it's on the order of a dozen pages
> used for the 2 extra sets of buckets. (E.g. it's well below the overhead
> introduced by CONFIG_RANDOM_KMALLOC_CACHES, which adds 16 extra sets
> of buckets.)

[1] https://lore.kernel.org/all/202404280921.A7683D511@keescook 

If the data still shows that the cost is still "dozens of pages"
for a few buckets w/o measurable performance overhead, I think that's
certainly doable.

> > 2. Making kmem_buckets tightly coupled with kmalloc's implementation
> >    details is not reasonable.
> > 
> > Let's say, at some point we make SLAB_BUCKETS always enabled and drop
> > the config option. Then all kmem_buckets users will now have certain
> > assumptions inherted from kmalloc (e.g. alignment), which is not
> > reasonable.
> 
> Until it's always enabled, I don't see a reasonable way to separate
> those assumptions.
> 
> > 3. __GFP_ACCOUNT and __GFP_DMA should be applied to all allocations
> > in the slab cache. For kmalloc, these flags are only used to select
> > the kmalloc cache (which has equivalent SLAB_* flags for __GFP_ACCOUNT
> > or __GFP_DMA) to serve the allocation.
> > 
> > Specifying it on individual allocations (rather than as SLAB_ flags)
> > makes it easy to break the assumption.
> 
> As in, you don't want a "pass-through" mode for __GFP_DMA?
> 
> It's a lot of overhead for __GFP_DMA to have multiple providers, so I'd
> rather allow kmem_buckets to allow pass-through (perhaps explicitly
> opt-in) where then the other options (e.g. alignment) must match the
> general kmalloc caches so that pass-through is consistent.

Having both "Specifying __GFP_DMA for slab caches without SLAB_DMA is
illegal" and "However kmem_buckets is an exception because creating
separate buckets for SLAB_DMA is costly" in mind is confusing and
easy to get wrong...

Perhaps the user should bypass kmem_buckets and fall back
to kmalloc?

> > > When it falls back to kmalloc, kmem_buckets itself should provide a
> > > compatibility layer when falling back to kmalloc.
> > 
> > For example, calculate_sizes() converts certain SLAB_* flags into
> > GFP flags (s->allocflags) for allocation. We can have a similar
> > logic when falling back to kmalloc.
> > 
> > Though current implementation does not allow this and requires
> > some rework.
> 
> I think the current series does everything correctly in the sense that
> nothing is allowing for mismatched fallbacks/passthrus. We could iterate
> from there once we have a need for this where a non-kmalloc-alignment is
> wanted, etc?

Making kmalloc tightly coupled with DMA alignment requirement was
a mistake, and now it's too late to fix that. It's better to not
repeat the same mistake again?

-- 
Cheers,
Harry / Hyeonggon

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Vlastimil Babka (SUSE)]

On 10/10/26 05:18, Kees Cook wrote:
> On Fri, Oct 09, 2026 at 09:39:48PM +0200, Harry Yoo wrote:
>> On Fri, Oct 09, 2026 at 04:22:03PM +0200, Harry Yoo wrote:
>> > And now I see the initial kmem_buckets design did not sufficiently
>> > tackle the question "How this should work when kmem_buckets falls back
>> > to kmalloc?"
>> > 
>> > I suppose the kmem_buckets' abstraction should not be too tightly
>> > coupled with kmalloc caches. Creating a kmem_buckets should be
>> > conceptually equivalent to creating a set of caches with speicifc
>> > slab flags, size, align, useroffset/size. (for variable size allocation).
>> 
>> Just to clarify... I have a few concerns on this area.
>> 
>> 1. Complexity.
>> 
>> It's very counter-intuitive to understand how it works when
>> SLAB_BUCKETS is not compiled. My brain cannot easily process two
>> different implementations w/ and w/o SLAB_BUCKETS.
>> 
>> A "compatibility layer" allows us to assume certain expectations
>> and ignore all implementation details when SLAB_BUCKETS is not compiled.
> 
> I'd rather make kmem_buckets not have a SLAB_BUCKETS option. :)

The tradeoff hardening vs memory footprint exists however, so I don't think
we can simply do that.

>> 2. Making kmem_buckets tightly coupled with kmalloc's implementation
>>    details is not reasonable.
>> 
>> Let's say, at some point we make SLAB_BUCKETS always enabled and drop
>> the config option. Then all kmem_buckets users will now have certain
>> assumptions inherted from kmalloc (e.g. alignment), which is not
>> reasonable.
> 
> Until it's always enabled, I don't see a reasonable way to separate
> those assumptions.

Agree. I don't think the assumptions are so problematic.

>> 3. __GFP_ACCOUNT and __GFP_DMA should be applied to all allocations
>> in the slab cache. For kmalloc, these flags are only used to select
>> the kmalloc cache (which has equivalent SLAB_* flags for __GFP_ACCOUNT
>> or __GFP_DMA) to serve the allocation.
>> 
>> Specifying it on individual allocations (rather than as SLAB_ flags)
>> makes it easy to break the assumption.
> 
> As in, you don't want a "pass-through" mode for __GFP_DMA?
> 
> It's a lot of overhead for __GFP_DMA to have multiple providers, so I'd
> rather allow kmem_buckets to allow pass-through (perhaps explicitly
> opt-in) where then the other options (e.g. alignment) must match the
> general kmalloc caches so that pass-through is consistent.

"pass-through" mode for __GFP_DMA seems reasonable to me. I hope we
eventually get rid of it, so I would support it in the most simple way possible.

>> > When it falls back to kmalloc, kmem_buckets itself should provide a
>> > compatibility layer when falling back to kmalloc.
>> 
>> For example, calculate_sizes() converts certain SLAB_* flags into
>> GFP flags (s->allocflags) for allocation. We can have a similar
>> logic when falling back to kmalloc.
>> 
>> Though current implementation does not allow this and requires
>> some rework.
> 
> I think the current series does everything correctly in the sense that
> nothing is allowing for mismatched fallbacks/passthrus. We could iterate
> from there once we have a need for this where a non-kmalloc-alignment is
> wanted, etc?

I think we can indeed simply make sure buckets have the same alignment as
kmalloc. It comes naturally and should (more than) satisfy everyone. I doubt
anyone would be needing a more specific alignment than that for a class of
allocations with a variable size?

ctor removal is clear I think

for __GFP_ACCOUNT and __GFP_RECLAIMABLE I think what we could do is not to
drop the flags argument kmem_buckets_create and instead require that it
matches the usage:

__GFP_RECLAIMABLE requires SLAB_RECLAIM_ACCOUNT and vice versa and I can't
imagine there would be a buckets instance that would allocate both kinds
(either with or without __GFP_RECLAIMABLE)

SLAB_ACCOUNT requires __GFP_ACCOUNT, memcg objexts are always created and used

SLAB_MAY_ACCOUNT allows __GFP_ACCOUNT, memcg objexts are always created, and
used when __GFP_ACCOUNT given
- perhaps not as optimal as the separate kmalloc types, but good enough?

__GFP_ACCOUNT without either SLAB_ACCOUNT or SLAB_MAY_ACCOUNT is wrong,
__GFP_ACCOUNT would be ignored

with SLAB_BUCKETS=y these rules could be checked e.g. with a VM_WARN_ON_ONCE()

with SLAB_BUCKETS=n these rules won't be checked but also not matter in practice

wdyt?

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Kees Cook]

On Mon, Oct 12, 2026 at 06:46:48PM +0200, Vlastimil Babka (SUSE) wrote:
> On 10/11/26 00:37, Andrew Morton wrote:
> > On Fri, 9 Oct 2026 20:14:20 -0700 Kees Cook <kees@kernel.org> wrote:
> > 
> >> Anything with Fixes: will end up in stable, so I just leave off the
> >> stable CC these days.
> > 
> > -stable maintainers have been asked to Not Do That for mm patches. 
> > Other subsystems are doing the same.
> > 
> > I don't know how they determine whether something is an mm patch.  A
> > patch which covers do-do-that and dont-do-that parts of the tree is
> > likely to be mishandled.
> > 
> > So yeah, add that cc:stable to reduce the possibility of mistakes.
> 
> There's also this from the list of pain points at
> https://lwn.net/Articles/1099594/
> 
>     Kroah-Hartman: subsystems that do not add CC: stable@vger.kernel.org
> tags to patches, but which still expect the stable team to pick up the
> important fixes anyway. The stable maintainers are overwhelmed as it is and
> are not doing that.

tl;dr: yup, sorry. I will add CC:stable in the future.

I went to go figure out where I had gotten this misunderstanding.
netdev dropped their special handling in 2021 in commit dbbe7c962c3a
("docs: networking: drop special stable handling"). But I
really thought I had Greg tell me (in person somewhere?) that
"Cc: stable" was redundant, and I think what I misread in current
docs was, "... such tagging is unnecessary if the stable
team can derive the appropriate versions from Fixes: tags." in
https://docs.kernel.org/process/stable-kernel-rules.html#stable-kernel-rules
but that, on closer reading, is about the _versioning_ syntax of the
"Cc: stable" trailer.

-- 
Kees Cook

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Kees Cook]

On Mon, Oct 12, 2026 at 11:03:18PM +0200, Vlastimil Babka (SUSE) wrote:
> On 10/12/26 19:55, Vlastimil Babka (SUSE) wrote:
> > On 10/6/26 11:20, Kees Cook wrote:
> >> Since commit 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for
> >> alloc_msg()"), alloc_msg() allocates with GFP_KERNEL, and a msg_msg is
> >> accounted only through SLAB_ACCOUNT on its bucket caches. With
> >> CONFIG_SLAB_BUCKETS=n, kmem_buckets_create() creates no caches and
> >> kmem_buckets_alloc() is a GFP_KERNEL kmalloc() from the general caches,
> >> which do not account it; the same happens when kmem_buckets_create()
> >> fails. Either way, the allocation is not charged to the sender's memory
> >> cgroup.
> >> 
> >> Allocate with GFP_KERNEL_ACCOUNT again, as before that commit. Memcg
> >> charges such an allocation in whichever cache serves it, so drop the
> >> SLAB_ACCOUNT, which no longer adds anything.
> >> 
> >> Build tested ARCH=x86_64 defconfig with GCC 16.2.0, with
> >> CONFIG_SLAB_BUCKETS as y and n.
> >> 
> >> Fixes: 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for alloc_msg()")
> >> Assisted-by: LLM
> >> Signed-off-by: Kees Cook <kees@kernel.org>
> > 
> > Could we, for the purposes of a backportable fix, just have both
> > SLAB_ACCOUNT and GFP_KERNEL_ACCOUNT in place? That should do the right thing
> > regardless of CONFIG_SLAB_BUCKETS state, no?
> 
> BTW we're thinking to add 1+2 (once this part is clarified) for 7.4 (with
> stable@ for patch 2). 

Yeah, I'll respin with it present on the create and the alloc sides.

> But for the rest we'll have to target 7.5 as it's only
> a week to the 7.4 merge window now.

Yeah, that's totally fine; I'm in no rush. I want to get it right, and
I'm still recovering from my surprise about how GFP_KERNEL_ACCOUNT
actually works. ;)

-- 
Kees Cook

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Kees Cook]

On Mon, Oct 12, 2026 at 11:19:01PM +0200, Vlastimil Babka (SUSE) wrote:
> On 10/10/26 05:18, Kees Cook wrote:
> > On Fri, Oct 09, 2026 at 09:39:48PM +0200, Harry Yoo wrote:
> >> On Fri, Oct 09, 2026 at 04:22:03PM +0200, Harry Yoo wrote:
> >> > When it falls back to kmalloc, kmem_buckets itself should provide a
> >> > compatibility layer when falling back to kmalloc.
> >> 
> >> For example, calculate_sizes() converts certain SLAB_* flags into
> >> GFP flags (s->allocflags) for allocation. We can have a similar
> >> logic when falling back to kmalloc.
> >> 
> >> Though current implementation does not allow this and requires
> >> some rework.
> > 
> > I think the current series does everything correctly in the sense that
> > nothing is allowing for mismatched fallbacks/passthrus. We could iterate
> > from there once we have a need for this where a non-kmalloc-alignment is
> > wanted, etc?
> 
> I think we can indeed simply make sure buckets have the same alignment as
> kmalloc. It comes naturally and should (more than) satisfy everyone. I doubt
> anyone would be needing a more specific alignment than that for a class of
> allocations with a variable size?

Right, the whole point of kmem_buckets was to replace general kmalloc
uses, where no callers cared about alignment.

> ctor removal is clear I think

Completely. I was blinded by the API of kmem_cache_create(). :)

> for __GFP_ACCOUNT and __GFP_RECLAIMABLE I think what we could do is not to
> drop the flags argument kmem_buckets_create and instead require that it
> matches the usage:
> 
> __GFP_RECLAIMABLE requires SLAB_RECLAIM_ACCOUNT and vice versa and I can't
> imagine there would be a buckets instance that would allocate both kinds
> (either with or without __GFP_RECLAIMABLE)

Okay. (We have no users of this yet, FWIW.)

> SLAB_ACCOUNT requires __GFP_ACCOUNT, memcg objexts are always created and used

Right.

> SLAB_MAY_ACCOUNT allows __GFP_ACCOUNT, memcg objexts are always created, and
> used when __GFP_ACCOUNT given
> - perhaps not as optimal as the separate kmalloc types, but good enough?

I think it's fine from studying what happens with the skb data. Though
right now, SLAB_ACCOUNT and SLAB_MAY_ACCOUNT are functionally identical,
yes?

> __GFP_ACCOUNT without either SLAB_ACCOUNT or SLAB_MAY_ACCOUNT is wrong,
> __GFP_ACCOUNT would be ignored

*ignored* is, I think, wrong here. It would create differing behavior
between SLAB_BUCKETS=y/n. If we passed __GFP_ACCOUNT through to general
kmalloc when the buckets lacked SLAB_ACCOUNT and SLAB_MAY_ACCOUNT, you'd
lose the isolation, but not the accounting. (And could WARN_ONCE about
it.) But if it was ignored, you'd lose accounting under
SLAB_BUCKETS=y.

> with SLAB_BUCKETS=y these rules could be checked e.g. with a VM_WARN_ON_ONCE()
> 
> with SLAB_BUCKETS=n these rules won't be checked but also not matter in practice

Agreed. That's what I was going for on this version. But like above,
"SLAB_ACCOUNT requires __GFP_ACCOUNT" means what? Under SLAB_BUCKETS=y
the allocation returns NULL? Or it passes through with WARN_ONCE? I'd
rather not break something completely; better to fallback on a mismatch
so the requested type happens (be it DMA, ACCOUNTing, etc).

-- 
Kees Cook

Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Vlastimil Babka (SUSE)]

On 10/13/26 10:52, Kees Cook wrote:
> On Mon, Oct 12, 2026 at 11:19:01PM +0200, Vlastimil Babka (SUSE) wrote:
>> On 10/10/26 05:18, Kees Cook wrote:
>> > On Fri, Oct 09, 2026 at 09:39:48PM +0200, Harry Yoo wrote:
>> >> On Fri, Oct 09, 2026 at 04:22:03PM +0200, Harry Yoo wrote:
>> >> > When it falls back to kmalloc, kmem_buckets itself should provide a
>> >> > compatibility layer when falling back to kmalloc.
>> >> 
>> >> For example, calculate_sizes() converts certain SLAB_* flags into
>> >> GFP flags (s->allocflags) for allocation. We can have a similar
>> >> logic when falling back to kmalloc.
>> >> 
>> >> Though current implementation does not allow this and requires
>> >> some rework.
>> > 
>> > I think the current series does everything correctly in the sense that
>> > nothing is allowing for mismatched fallbacks/passthrus. We could iterate
>> > from there once we have a need for this where a non-kmalloc-alignment is
>> > wanted, etc?
>> 
>> I think we can indeed simply make sure buckets have the same alignment as
>> kmalloc. It comes naturally and should (more than) satisfy everyone. I doubt
>> anyone would be needing a more specific alignment than that for a class of
>> allocations with a variable size?
> 
> Right, the whole point of kmem_buckets was to replace general kmalloc
> uses, where no callers cared about alignment.
> 
>> ctor removal is clear I think
> 
> Completely. I was blinded by the API of kmem_cache_create(). :)
> 
>> for __GFP_ACCOUNT and __GFP_RECLAIMABLE I think what we could do is not to
>> drop the flags argument kmem_buckets_create and instead require that it
>> matches the usage:
>> 
>> __GFP_RECLAIMABLE requires SLAB_RECLAIM_ACCOUNT and vice versa and I can't
>> imagine there would be a buckets instance that would allocate both kinds
>> (either with or without __GFP_RECLAIMABLE)
> 
> Okay. (We have no users of this yet, FWIW.)
> 
>> SLAB_ACCOUNT requires __GFP_ACCOUNT, memcg objexts are always created and used
> 
> Right.
> 
>> SLAB_MAY_ACCOUNT allows __GFP_ACCOUNT, memcg objexts are always created, and
>> used when __GFP_ACCOUNT given
>> - perhaps not as optimal as the separate kmalloc types, but good enough?

Ah there's already a precedent, e.g. specifying __GFP_RECLAIM means you get
a KMALLOC_RECLAIM cache, but it may or may not be accounted depending on
passing also __GFP_ACCOUNT and there are no separate sets of slabs for
these. Also same can happen with kmem_cache_create() cache when only some
allocations are __GFP_ACCOUNT.
> I think it's fine from studying what happens with the skb data. Though
> right now, SLAB_ACCOUNT and SLAB_MAY_ACCOUNT are functionally identical,
> yes?

Both mean that objcg pointers might exist for the slabs from the cache, but
SLAB_ACCOUNT also implies __GFP_ACCOUNT for every allocation from the cache
even if not given. But for kmem_bucket_alloc() with SLAB_BUCKETS=n with we
have nowhere to store that this implication should be done (that would be
the "compatibility layer").

>> __GFP_ACCOUNT without either SLAB_ACCOUNT or SLAB_MAY_ACCOUNT is wrong,
>> __GFP_ACCOUNT would be ignored
> 
> *ignored* is, I think, wrong here. It would create differing behavior
> between SLAB_BUCKETS=y/n.

Yes that's why we must avoid it. SLAB_MAY_ACCOUNT is a new thing and because
there were already many caches that may or may not pass __GFP_ACCOUNT, we
just assume it for now in __kmem_cache_create_args(). But that's a TODO to
start tightening it. With buckets we only have a handful of users so we
could try doing that right away, and have warnings in place to catch any
changes that push it into the "wrong" state.

> If we passed __GFP_ACCOUNT through to general
> kmalloc when the buckets lacked SLAB_ACCOUNT and SLAB_MAY_ACCOUNT, you'd
> lose the isolation, but not the accounting. (And could WARN_ONCE about
> it.) But if it was ignored, you'd lose accounting under
> SLAB_BUCKETS=y.

We could warn and fallback then, I guess.

>> with SLAB_BUCKETS=y these rules could be checked e.g. with a VM_WARN_ON_ONCE()
>> 
>> with SLAB_BUCKETS=n these rules won't be checked but also not matter in practice
> 
> Agreed. That's what I was going for on this version. But like above,
> "SLAB_ACCOUNT requires __GFP_ACCOUNT" means what? Under SLAB_BUCKETS=y
> the allocation returns NULL? Or it passes through with WARN_ONCE? I'd

"SLAB_ACCOUNT requires __GFP_ACCOUNT" means that if it's not done and
SLAB_BUCKETS=n, then we get the issue that patch 2 fixes, and have no way to
actually find out and warn that it's the case (with SLAB_BUCKETS=n... the
warning can be issued with SLAB_BUCKETS=y and then it passes through as if
there was __GFP_ACCOUNT).

> rather not break something completely; better to fallback on a mismatch
> so the requested type happens (be it DMA, ACCOUNTing, etc).

Also instead of the scheme above, maybe we could explore the idea of
"compatibility layer" too. It would mean that even with SLAB_BUCKETS=n,
kmem_buckets_create() would create some object to hold the gfp_flags we want
to append to all allocations from that bucket. But then kmem_buckets_alloc()
would have to do something a bit more than map to __kmalloc_node_noprof
(with PASS_KMALLOC_PARAMS directly). Of course SLAB_BUCKETS=y would be using
this way too then to avoid further complication. Maybe the result would be
more cleaner (simplifying PASS_KMALLOC_PARAMS and getting rid of
PASS_BUCKET_PARAMS?) but I can't say immediately how well it would work.