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