net: skb: isolate skb data area allocations into a separate bucket

kmem_buckets_create() had the same sentence about calling context as kmem_cache_create(), but lacked the "Context:" prefix, so kernel-doc rendered in the body instead of as a "context" section.

Give it the missing prefix. Additionally fix the "a interrupt" typo __kmem_cache_create_args() had.

Fixes b32801d1255be ("mm/slab: Introduce kmem_buckets_create() and family")

Assisted-by LLM

Reviewed-by Harry Yoo (Meta) <[email protected]>

Acked-by Pedro Falcato <[email protected]>

Reviewed-by Hao Li <[email protected]>

Signed-off-by Kees Cook <[email protected]>

---
 mm/slab_common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

mm/slab_common.c +2 -2

index b19ba1b31484..270408ce5a9d 100644
@@ -311,7 +311,7 @@ __kmem_cache_alias(const char *name, unsigned int size, slab_flags_t flags,
  * &SLAB_TYPESAFE_BY_RCU - Slab page (not individual objects) freeing delayed
  * by a grace period - see the full description before using.
  *
- * Context: Cannot be called within a interrupt, but can be interrupted.
+ * Context: Cannot be called within an interrupt, but can be interrupted.
  *
  * Return: a pointer to the cache on success, NULL on failure.
  */

@@ -422,7 +422,7 @@ static struct kmem_cache *kmem_buckets_cache __ro_after_init;
  *		to/from userspace.
  * @ctor: A constructor for the objects, run when new allocations are made.
  *
- * Cannot be called within an interrupt, but can be interrupted.
+ * Context: Cannot be called within an interrupt, but can be interrupted.
  *
  * Return: a pointer to the cache on success, NULL on failure. When
  * CONFIG_SLAB_BUCKETS is not enabled, ZERO_SIZE_PTR is returned, and

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 <[email protected]>

---
 ipc/msgutil.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

ipc/msgutil.c +3 -2

index e28f0cecb2ec..1ba8e59cb255 100644
@@ -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;

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.

Quoted 8 lines · Harry Yoo

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.

Quoted 2 lines

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.

Quoted 14 lines · Harry Yoo

Quoted 8 lines · Harry Yoo

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.

Quoted 6 lines

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. :)

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

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 2 lines

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?

Quoted 14 lines · Harry Yoo

Quoted 8 lines · Harry Yoo

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.

Quoted 6 lines

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. :)

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 2 lines

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?

Quoted 9 lines · Kees Cook

Quoted 8 lines · Harry Yoo

Quoted 2 lines · Harry Yoo

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.

Quoted 7 lines

Quoted 2 lines

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

Quoted 18 lines · Vlastimil Babka (SUSE)

Quoted 9 lines · Kees Cook

Quoted 8 lines · Harry Yoo

Quoted 2 lines · Harry Yoo

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.

Quoted 7 lines

Quoted 2 lines

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?

Quoted 4 lines

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.

Quoted 1 line

ctor removal is clear I think

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

Quoted 7 lines

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

Quoted 1 line

SLAB_ACCOUNT requires __GFP_ACCOUNT, memcg objexts are always created and used

Right.

Quoted 3 lines

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?

Quoted 2 lines

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

Quoted 3 lines

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

Quoted 10 lines · 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.

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.

Quoted 3 lines

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/[email protected]

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? :-)

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

Quoted 2 lines · On Fri, 9 Oct 2026 20:14:20 -0700 Kees Cook <[email protected]> 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.

Quoted 5 lines · Andrew Morton

Quoted 2 lines · On Fri, 9 Oct 2026 20:14:20 -0700 Kees Cook <[email protected]> wrote:

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

Quoted 8 lines

-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: [email protected]
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.

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 <[email protected]>

---
 ipc/msgutil.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

ipc/msgutil.c +3 -2

index e28f0cecb2ec..1ba8e59cb255 100644
@@ -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;
 

Quoted 16 lines · 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.

Quoted 3 lines

Fixes 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for alloc_msg()")

Assisted-by LLM

Signed-off-by Kees Cook <[email protected]>

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?

Quoted 21 lines · Vlastimil Babka (SUSE)

Quoted 19 lines · 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 <[email protected]>

Quoted 3 lines

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.

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?

Quoted 1 line · Kees Cook

Hi!

Hi Kees!

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

Quoted 1 line

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.

Quoted 1 line

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.

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

Quoted 1 line · Kees Cook

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

Quoted 2 lines

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

Cool!

Quoted 7 lines

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.

Quoted 8 lines

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.

Quoted 1 line

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.

Quoted 4 lines

And the whole
exploration made me realize I had a completely wrong understanding of how memcg worked. :P

Quoted 2 lines

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?