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: <07f871a2-f993-405d-9ffa-0c9a5f18b3d6@lucifer.local>
Date: Tue, 8 Jul 2025 15:06:13 +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 03:41:31PM +0200, Danilo Krummrich wrote:
> On Tue Jul 8, 2025 at 2:36 PM CEST, Lorenzo Stoakes wrote:
> > TL;DR - the real issue here is not cc'ing the right people (Vlastimil was
> > not cc'd until v11 for instance).
>
> Since Andrew was Cc'd and also did reply, but didn't mention anything about
> missing receipients on the -mm side of things, I did not see a reason to bring
> anything up regarding this from my end.
>
> Thanks for bringing this up.

No problem - and it's understandable that it wouldn't quite be clear that
it's important to cc- as many people, as things have recently changed a lot
in mm re: having a good + specific response from get_maintainers.pl.

At any rate, it's important to always include M's/R's from
get_maintainers.pl as a matter of course when submitting series.

>
> > 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/*
> >
> > this ---> rust/helpers/slab.c            | 10 +++---
> > this ---> rust/helpers/vmalloc.c         |  5 +--
>
> So, your concern is about those?
>
> > These are clearly specifically related to mm no?
>
> Yes, and if the maintainers of slab and vmalloc agree we can add them there.

And the mm/rust section. Because if that's not where we put files that
relate to mm/rust, what is it for?

I think it turns out the larger question here is really about the alloc
stuff. I raised that in a separate thread.

>
> But again, they're just re-exporting inline functions and macros from header
> files, which bindgen does not pick up automatically. They do not carry any logic
> and purely are a workaround for bindgen.
>
> For instance,
>
> void * __must_check __realloc_size(2)
> 	rust_helper_vrealloc(const void *p, size_t size, gfp_t flags)
> 	{
> 	        return vrealloc(p, size, flags);
> 	}
>
> works around bindgen not picking up the vrealloc() macro.

Thanks for the explanation - that's useful.

So the fact these came up by accident more or less I think underlines the
broader need for a conversation about about what does/doesn't constitute
mm/rust.

But perhaps best to keep that to the thread where I raise the alloc stuff.