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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

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.