[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

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

[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.