Message-Id: <DD1SGLU4180C.361W5XLH76XNC@kernel.org>
Date: Thu, 25 Sep 2025 11:54:22 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Elijah Wright" <git@...jahs.space>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor"
 <alex.gaynor@...il.com>, "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo"
 <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>, "Andreas
 Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl" <aliceryhl@...gle.com>,
 "Trevor Gross" <tmgross@...ch.edu>, <rust-for-linux@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, "Lorenzo Stoakes"
 <lorenzo.stoakes@...cle.com>, "Vlastimil Babka" <vbabka@...e.cz>, "Liam R.
 Howlett" <Liam.Howlett@...cle.com>, "Uladzislau Rezki" <urezki@...il.com>,
 <linux-mm@...ck.org>
Subject: Re: [PATCH] rust: slab: add basic slab module

(+Cc: Lorenzo, Vlastimil, Liam, Uladzislau, MM)

On Wed Sep 24, 2025 at 9:36 PM CEST, Elijah Wright wrote:
> this patch adds a basic slab module for kmem_cache, primarily wrapping
> kmem_cache_create, kmem_cache_alloc, kmem_cache_free, and kmem_cache_destroy.

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.

- Danilo

[1] https://rust.docs.kernel.org/kernel/alloc/allocator/struct.Kmalloc.html
[2] https://rust.docs.kernel.org/kernel/alloc/allocator/struct.Vmalloc.html
[3] https://rust.docs.kernel.org/kernel/alloc/kbox/type.KBox.html
[4] https://rust.docs.kernel.org/kernel/alloc/kbox/type.VBox.html
[5] https://rust.docs.kernel.org/kernel/alloc/trait.Allocator.html

Powered by blists - more mailing lists