Re: [PATCH net-next v3] net: skb: isolate skb data area allocations into a separate bucket

[Kees Cook]

On July 15, 2026 4:07:49 AM PDT, Pedro Falcato <pfalcato@xxxxxxx> 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