On July 15, 2026 4:07:49 AM PDT, Pedro Falcato <[email protected]> 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) ;)
>
>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.
How about dropping non-standard flag alloc requests into the general kmalloc
buckets? (I.e. have kmem_buckets_alloc redirect on flag mismatch?)
-Kees
--
Kees Cook
