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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54fc10ce-c3b6-4571-93e7-eebfc538d0c7@lucifer.local>
Date: Tue, 8 Jul 2025 14:19:38 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Danilo Krummrich <dakr@...nel.org>
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 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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ