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

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

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCalg9hwAKCRCGXBN6rc5S
1qiTAQDBTgHUQNlbhhV0KovqNCHl2aAaCrah376xCdTsuaTvSAD8Cg9gheKulpHN
2nrpaiNOraIrtk8ZpVzV4Gwnh3mEJQI=
=PjPB
-----END PGP SIGNATURE-----