linux-kernel - Re: [PATCH v11 0/4] support large align and nid in Rust allocators

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aG5TE3oq1w1cSdOy@google.com>
Date: Wed, 9 Jul 2025 11:31:31 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Danilo Krummrich <dakr@...nel.org>, Vitaly Wool <vitaly.wool@...sulko.se>, linux-mm@...ck.org, 
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org, 
	Uladzislau Rezki <urezki@...il.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 08, 2025 at 02:19:38PM +0100, Lorenzo Stoakes wrote:
> On Tue, Jul 08, 2025 at 01:55:18PM +0200, Danilo Krummrich wrote:
> > On Tue, Jul 08, 2025 at 11:58:06AM +0100, Lorenzo Stoakes wrote:
> > > +cc Liam
> > >
> > > Hi guys,
> > >
> > > We have a section in MAINTAINERS for mm rust (MEMORY MANAGEMENT - RUST), so
> > > it's slightly concerning to find a series (at v11!) like this that changes
> > > mm-related stuff and it involves files not listed there and nobody bothered
> > > to cc- the people listed there.
> >
> > What files are you referring to? Are you referring to:
> >
> > 	rust/kernel/alloc.rs
> > 	rust/kernel/alloc/*
> >
> > If so, they're indeed not under the "MEMORY MANAGEMENT - RUST" entry, which
> > so far seems correct.
> 
> Looking at these, they seem to be intended to be the primary means by which
> slab/vmalloc allocations will be managed in rust kernel code correct?
> 
> There's also stuff relating to NUMA etc.
> 
> I really do wonder where the line between this and the mm stuff is. Because
> if the idea is 'well this is just a wrapper around slab/vmalloc' surely the
> same can be said of what's in rust/kernel/mm.rs re: VMAs?
> 
> So if this is the rust equivalent of include/linux/slab.h and mm/slub.c
> then that does seem to me to suggest this should be considered an mm/rust
> thing right?
> 
> It'd be good to know exactly what is considered mm rust and should go
> through the mm tree and what isn't.
> 
> Maybe Alice has some insights on this?

The Rust standard library has three pieces:

- core. Defines standard types that can work anywhere. (such as ints)
- alloc. Defines standard types that require an allocator. (such as vectors)
- std. Defines standard types that require an OS. (such as File or TcpStream)

In the kernel we used to use both core and alloc, but we switched away
from alloc because it doesn't support GFP flags well. The 'RUST [ALLOC]'
subsystem originates from that transition from the Rust stdlib alloc to
our own implementation. It contains essentially three pieces:

- Two data structures Vec and Box.
  - The Box data structure is the simplest possible user of allocation:
    A Box<T> stores a single instance of the struct T in its own
    allocation.
  - The Vec data structure stores a resizable array and maintains a
    pointer, length, capacity triplet. There is a bunch of logic to
    manipulate these to correctly keep track of which parts of the
    vector are in use.
- The Allocator trait.
  - This trait defines what functions an allocator must provide.
  - The data structures Box or Vec require you to specify an allocator,
    and internally it calls into the allocator to manage the backing
    memory for its data.
- Three concrete implementations of the Allocator trait.
  - These are kmalloc, vmalloc, and kvmalloc respectively.

In my eyes, the further down this list you get, the more likely it is
that the patch needs to go through the MM tree.

Alice