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

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

On Tue, Apr 15, 2025 at 09:14:47AM -0700, Suren Baghdasaryan wrote:
> On Tue, Apr 15, 2025 at 8:43 AM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > On Tue, Apr 15, 2025 at 11:37:04AM -0400, Liam R. Howlett wrote:
> > > * Lorenzo Stoakes <lorenzo.stoakes@oracle.com> [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@oracle.com>
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>

Thanks!

>
> > > > ---
> > > >  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@linux-foundation.org>
> > > > +M: Suren Baghdasaryan <surenb@google.com>
> > > > +R: Liam R. Howlett <Liam.Howlett@oracle.com>
> > > > +R: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > > +R: Vlastimil Babka <vbabka@suse.cz>
> > > > +L: linux-mm@kvack.org
> > > > +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?
>
> Thanks for trusting me with the maintenance. I'll do my best not to betray it.
> I agree that you and Liam have reviewed this code enough times to make
> informed decisions. Other good candidates include Jann and Vlastimil.
> David already reviews the entire mm codebase, so adding him is
> probably unnecessary.

Thanks, will update my and Liam's R's to M's.

David of course will always get my vote but I feel he's far too busy on
this one.

Jann and Vlastimil are also suitable, I believe Jann is away, Vlastimil can
shout if he really wants M but I suspect he's probably fine with the R :>)

>
> >
> > >
> > > 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 :), though I
> > _don't think_ either Shakeel or Jann really actively work with mmap/VMA
> > locks (forgive me if I am mistaken) so wouldn't really be suitable for M as
> > I feel that requires some active development.
> >
> > >
> > > > +
> > > >  MEMORY MAPPING - MADVISE (MEMORY ADVICE)
> > > >  M: Andrew Morton <akpm@linux-foundation.org>
> > > >  M: Liam R. Howlett <Liam.Howlett@oracle.com>
> > > > --
> > > > 2.49.0
> > > >