Re: [PATCH] rust: slab: add basic slab module

["Danilo Krummrich" <dakr@kernel.org>]

On Thu Sep 25, 2025 at 7:20 PM CEST, Elijah wrote:

Please don't top post [1]; use interleaved style instead.

[1] https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying

> I was thinking of maybe creating something like KBox for kmem_cache but 
> I didn't want to touch allocator code yet, I figured I would just create 
> the groundwork for that to exist. rbtree.rs uses KBox now but I'm not 
> sure it should, at least if it's going to scale to many nodes

Ok, so you want to support kmemcache for rbtree nodes. Ideally, you should also
have a use-case for that, but given that we'll also need kmemcache in other
drivers (such as Nova) anyways, I think that's fine.

However, in any case this should be integrated into the rust/kernel/alloc/
infrastructure in one of the ways described below.

As mentioned, I would like to see (3) or (4). (2) may be viable as well, but I
really hate the resulting code duplication (not having dynamic dispatch for a
kmemcache backed Box is probably not that big of a deal though).

Anyways, I'd also like to hear some more opinions, especially regarding (4), as
mentioned.

> On 9/25/2025 2:54 AM, Danilo Krummrich wrote:
>> What's the motivation?
>> 
>> I mean, we will need kmem_cache soon. But the users will all be drivers, e.g.
>> the GPU drivers that people work on currently.
>> 
>> Drivers shouldn't use "raw" allocators (such as Kmalloc [1] or Vmalloc [2]), but
>> the corresponding "managed" allocation primitives, such as KBox [3], VBox [4],
>> KVec, etc.
>> 
>> Therefore, the code below shouldn't be used by drivers directly, hence the
>> question for motivation.
>> 
>> In any case, kmem_cache is a special allocator (special as in it can have a
>> non-static lifetime in contrast to other kernel allocators) and should be
>> integrated with the existing infrastructure in rust/kernel/alloc/.
>> 
>> I think there are multiple options for that; (1) isn't really an option, but I
>> think it's good to mention anyways:
>> 
>>    (1) Allow for non-zero sized implementations of the Allocator trait [3], such
>>        that we can store a reference count to the KmemCache. This is necessary to
>>        ensure that a Box<T, KmemCache> can't out-live the KmemCache itself.
>> 
>>        The reason why I said it's not really an option is because it discards the
>>        option for dynamic dispatch of the generic Box type.
>> 
>>    (2) Same as (1), but with a custom Box type. This keeps dynamic dispatch for
>>        the generic Box type (i.e. KBox, VBox, KVBox), but duplicates quite some
>>        code and still doesn't allow for dynamic dispatch for the KmemCacheBox.
>> 
>>    (3) Implement a macro to generate a custom KmemCache Allocator trait
>>        implementation for every KmemCache instance with a static lifetime.
>> 
>>        This makes KmemCache technically equivalent to the other allocators, such
>>        as Kmalloc, etc. but obviously has the downside that the KmemCache might
>>        live much longer than required.
>> 
>>        Technically, most KmemCache instances live for the whole module lifetime,
>>        so it might be fine though.
>> 
>>        (This is what I think Alice proposed.)
>> 
>>    (4) Solve the problem on the C side and let kmem_cache_alloc() take care of
>>        acquiring a reference count to the backing kmem_cache. The main question
>>        here would be where to store the pointer for decreasing the reference
>>        count on kmem_cache_free().
>> 
>>        Theoretically, it could be stored within the allocation itself, but it's a
>>        bit of a yikes.
>> 
>>        However, it would resolve all the mentioned problems above.
>> 
>> I'd like to see (3) or (4), also depending on what the MM folks think.