Re: [PATCH 2/2] MAINTAINERS: add section for locking of mm's and VMAs

[Shakeel Butt]

On Tue, Apr 15, 2025 at 04:43:41PM +0100, Lorenzo Stoakes wrote:
> On Tue, Apr 15, 2025 at 11:37:04AM -0400, Liam R. Howlett wrote:
> > * Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> [250415 09:11]:
> > > We place this under memory mapping as related to memory mapping
> > > abstractions in the form of mm_struct and vm_area_struct (VMA). Now we have
> > > separated out mmap/vma locking logic into the mmap_lock.c and mmap_lock.h
> > > files, so this should encapsulate the majority of the mm locking logic in
> > > the kernel.
> > >
> > > Suren is best placed to maintain this logic as the core architect of VMA
> > > locking as a whole.
> > >
> > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
> > > ---
> > >  MAINTAINERS | 15 +++++++++++++++
> > >  1 file changed, 15 insertions(+)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 8d834514a047..ce55676a16a4 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -15595,6 +15595,21 @@ F:	mm/vma_internal.h
> > >  F:	tools/testing/selftests/mm/merge.c
> > >  F:	tools/testing/vma/
> > >
> > > +MEMORY MAPPING - LOCKING
> > > +M:	Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> > > +M:	Suren Baghdasaryan <surenb@xxxxxxxxxx>
> > > +R:	Liam R. Howlett <Liam.Howlett@xxxxxxxxxx>
> > > +R:	Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
> > > +R:	Vlastimil Babka <vbabka@xxxxxxx>
> > > +L:	linux-mm@xxxxxxxxx
> > > +S:	Maintained
> > > +W:	http://www.linux-mm.org
> > > +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > > +F:	Documentation/mm/process_addrs.rst
> > > +F:	include/linux/mmap_lock.h
> > > +F:	include/trace/events/mmap_lock.h
> > > +F:	mm/mmap_lock.c
> >
> > It would be good to have more M's here in the case Suren is away or
> > whatever.
> >
> > I have worked on the mmap locking due to the maple tree addition, and I
> > have helped with vma locking in some areas.
> >
> > Lorenzo wrote the locking document, which Suren pointed out last mmap
> > lock meeting and does make locking changes.
> >
> > Are there others that could be M here?
> 
> I mean I'm fine to take an M here, based on having done _some_ work in this
> area and being involved in the meetings and documenting, though I'd largely
> defer to Suren who was the true expertise, and I also feel Liam has better
> knowledge than I do.
> 
> So I suggest probably, unless there are other viable and active takers, we
> should M myself and you Liam?
> 
> >
> > Shakeel and/or Jann might be good additions to this list somewhere
> > (looking at the edits to the file).
> 
> Don't mind R in these cases if Shakeel or Jann want of course :),

Thanks Liam. I don't mind an R here if you decide to send a new version.

Reviewed-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>