On 7/15/26 8:07 PM, Pedro Falcato wrote:
> On Wed, Jul 08, 2026 at 10:27:54PM +0900, Harry Yoo wrote:
>> On 7/8/26 8:16 PM, Pedro Falcato wrote:
>>> On Wed, Jul 08, 2026 at 10:30:50AM +0200, Paolo Abeni wrote:
>>>> On 7/2/26 7:07 PM, Pedro Falcato wrote:> @@ -586,6 +586,8 @@ struct
>>>> sk_buff *napi_build_skb(void *data, unsigned int frag_size)
>>>>> }
>>>>> EXPORT_SYMBOL(napi_build_skb);
>>>>>
>>>>> +static kmem_buckets *skb_data_buckets __ro_after_init;
>>>>> +
>>>>> static void *kmalloc_pfmemalloc(size_t obj_size, gfp_t flags, int node)
>>>>> {
>>>>> if (!gfp_pfmemalloc_allowed(flags))
>>>>> @@ -593,7 +595,8 @@ static void *kmalloc_pfmemalloc(size_t obj_size,
>>>>> gfp_t flags, int node)
>>>>> if (!obj_size)
>>>>> return kmem_cache_alloc_node(net_hotdata.skb_small_head_cache,
>>>>> flags, node);
>>>>> - return kmalloc_node_track_caller(obj_size, flags, node);
>>>>> + return kmem_buckets_alloc_node_track_caller(skb_data_buckets, obj_size,
>>>>> + flags, node);
>>>>
>>>> Sashiko noted that some drivers may require GFP_DMA buckets, and the
>>>> above may break them:
>>>>
>>>> https://sashiko.dev/#/patchset/20260702170728.168755-1-pfalcato%40suse.de
>>>
>>> Oh, this is really awkward. Adding linux-mm and slab maintainers for input
>>> here.
>>>
>>> Considering the current slab bucketing does not seem to duplicate DMA or
>>> CGROUP caches, could it make sense to duplicate those as well?
>>
>> Could we specify what kmalloc types the user needs when creating
>> kmem_buckets and duplicate caches for the requested kmalloc types only?
>
> Perhaps. But do the users themselves know? alloc_skb() allows users to specify
> random __GFP flags. We're bound to see some random caller do
> alloc_skb(__GFP_ACCOUNT) ;)Other users don't expose the buckets to drivers, so I thought only alloc_skb() would create the buckets for each kmalloc type. > In all honesty, I'm not quite sure what the best way forward here is. The most > transparent way is to bucket those other kmalloc types as well, but that might > very trivially result in a lot more caches (and possibly memory usage) for no > great reason. So perhaps specifying caches might do. Another direction could be merging those buckets. If we want to protect kmalloc objects from user-controllable allocations, can we create buckets for each kmalloc type during the boot process and let the kmem_buckets users share them? That doesn't sound like creating too many kmalloc caches, while providing a decent separation. We already have two buckets users, one w/ SLAB_ACCOUNT and the other w/o SLAB_ACCOUNT. If you really want each bucket to have a separate set of caches, you have to sacrifice some memory for security :) -- Cheers, Harry / Hyeonggon
OpenPGP_signature.asc
Description: OpenPGP digital signature
