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