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

Danilo Krummrich
2025-09-25T17:43:12Z

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.