Message-Id: <DB6RQCZYHPSA.1UEPUVMC3FBBI@kernel.org>
Date: Tue, 08 Jul 2025 17:11:28 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>
Cc: "Vitaly Wool" <vitaly.wool@...sulko.se>, <linux-mm@...ck.org>,
 <akpm@...ux-foundation.org>, <linux-kernel@...r.kernel.org>, "Uladzislau
 Rezki" <urezki@...il.com>, "Alice Ryhl" <aliceryhl@...gle.com>, "Vlastimil
 Babka" <vbabka@...e.cz>, <rust-for-linux@...r.kernel.org>, "Liam Howlett"
 <liam.howlett@...cle.com>
Subject: Re: [PATCH v11 0/4] support large align and nid in Rust allocators

On Tue Jul 8, 2025 at 4:39 PM CEST, Lorenzo Stoakes wrote:
> On Tue, Jul 08, 2025 at 04:16:48PM +0200, Danilo Krummrich wrote:
>> (Please also see the explanation in [1].)
>>
>> There's a thin abstraction layer for allocators in Rust, represented by the
>> kernel's Allocator trait [2] (which has a few differences to the Allocator trait in
>> upstream Rust, which, for instance, can't deal with GFP flags).
>>
>> This allocator trait is implemented by three backends, one for each of
>> krealloc(), vrealloc() and kvrealloc() [3].
>>
>> Otherwise, the alloc module implements Rust's core allocation primitives Box and
>> Vec, which each of them have a type alias for allocator backends. For instance,
>> there is KBox, VBox and KVBox [4].
>>
>> This was also mentioned in the mm rework in [5] and in the subsequent patch
>> series reworking the Rust allocator module [6].
>>
>> Before [6], the Rust allocator module only covered the kmalloc allocator (i.e.
>> krealloc()) and was maintained under the "RUST" entry.
>>
>> Since [6], this is maintained under the "RUST [ALLOC]" entry by me.
>>
>> Given that, there is a clear and documented responsibility, which also Andrew is
>> aware of.
>>
>> To me the current setup looks reasonable, but feel free to take a look at the
>> code and its relationship to mm and Rust core infrastructure and let me know
>> what you think -- I'm happy to discuss other proposals.
>
> Thanks for the explanation.
>
> To me this is clearly mm rust code. This is an abstraction over mm bits to
> provide slab or vmalloc allocations for rust bits.
>
> To be clear - I'm not suggesting anything dramatic here, nor in any way
> suggesting you ought not maintain this (apologies if this wasn't clear :)
>
> It's really a couple points:
>
> 1. Purely pragmatically - how can we make sure relevant people are pinged?

I'm very happy to add more reviewers to the RUST [ALLOC] entry for this purpose.

Can you please send a patch for this?

> 2. Having clarity on what does/does not constitute 'MEMORY MANAGEMENT - RUST'
>    (again, perhaps Alice best placed to give some input here from her point of
>    view).

In the end that's a question of definition.

The reason RUST [ALLOC] is a thing is because it is very closely related to Rust
core infrastructure with only a thin backend using {k,v}realloc().

Compared to other abstractions, the main purpose is not to expose a Rust
interface for an existing kernel specific API, but rather implement a very Rust
specific concept while being a user of an existing kernel C API.

> We could solve 1 very simply by just using the fact we can have files in
> multiple sections in MAINTAINERS.

Please not -- I don't want to have files in multiple entries in MAINTAINERS,
especially when there are different maintainers and different trees. I prefer
clear responsibility.

> Doing a scripts/get_maintainers.pl invocation will very clearly tell you
> who's in charge of what so there'd be no lack of clarity on this.

How's that when a file is in multiple entries?

> It's a bit messy, obviously. But it'd solve the issue of mm people not
> getting notified when things change.
>
> However, at this stage you might want to just limit this to people who have
> _opted in_ to look at mm/rust stuff. In which case then it'd make sense to
> add only to the "MEMORY MANAGEMENT - RUST" section (but here we need to
> address point 2 obviously).
>
> Alternatively we could just add reviewers to the rust alloc bit.

Yeah, let's do that instead please.

>>
>> [1] https://lore.kernel.org/all/aG0HJte0Xw55z_y4@pollux/
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust/kernel/alloc.rs#n139
>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust/kernel/alloc/allocator.rs#n130
>> [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust/kernel/alloc/kbox.rs
>> [5] https://lore.kernel.org/all/20240722163111.4766-1-dakr@kernel.org/
>> [6] https://lore.kernel.org/all/20241004154149.93856-1-dakr@kernel.org/
>
>
> I feel it's really important to not separate rust _too much_ from the
> subsystems it utilises - if we intend to have rust be used more and more
> and integrated further in the kernel (something I'd like to see, more so
> when I learn it :P) - the only practical way forward is for the rust stuff
> to be considered a first class citizen and managed hand-in-glove with the
> not-rust stuff.

You're preaching to the choir with this on my end. I'm recommending subsystems
that receive the first Rust bits to get involved in one or the other way all
the time. And if it's only by reading along. :)

Powered by blists - more mailing lists