Re: [PATCH] MAINTAINERS: update MEMORY MAPPING section

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

On Wed, Dec 11, 2024 at 10:36:42AM -0800, Jeff Xu wrote:
> On Wed, Dec 11, 2024 at 2:53 AM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > Update the MEMORY MAPPING section to contain VMA logic as it makes no
> > sense to have these two sections separate.
> >
> > Additionally, add files which permit changes to the attributes and/or
> > ranges spanned by memory mappings, in essence anything which might alter
> > the output of /proc/$pid/[s]maps.
> >
> > This is necessarily fuzzy, as there is not quite as good separation of
> > concerns as we would ideally like in the kernel. However each of these
> > files interacts with the VMA and memory mapping logic in such a way as to
> > be inseparatable from it, and it is important that they are maintained in
> > conjunction with it.
> >
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > ---
> >  MAINTAINERS | 23 ++++++++---------------
> >  1 file changed, 8 insertions(+), 15 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 68d825a4c69c..fb91389addd7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -15071,7 +15071,15 @@ 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:     mm/mlock.c
> >  F:     mm/mmap.c
> > +F:     mm/mprotect.c
> > +F:     mm/mremap.c
> > +F:     mm/mseal.c
> > +F:     mm/vma.c
> > +F:     mm/vma.h
> > +F:     mm/vma_internal.h
> > +F:     tools/testing/vma/
> >
> Will  madvise be here too ?

No. We had a long discussion about this on another version of this patch :)
it's blurry lines but it, in the end, is too much related to things other
than VMA logic.

We probably need better separation of stuff, but that's another thing...

> I'd like to be added as a reviewer on mm/mseal.c.  Is there any way to
> indicate this from this file ?

This is something we can consider in the future, sure.

However at this time you have had really significant issues in engaging
with the community on a regular basis, so I think the community is unlikely
to be open to this until you have improved in this area.

You will, of course, remain cc'd on any mseal changes regardless, so
functionally nothing will differ.

And equally, this change doesn't alter my or Liam's role, we will apply the
same review regardless.

The purpose of this change is, as the message says, to ensure the integrity
and maintainership of logic relating to memory mapping, and mseal is really
entirely a VMA operation so has to be included as a result.

So it is administrative in nature, ultimately.

>
> >  MEMORY TECHNOLOGY DEVICES (MTD)
> >  M:     Miquel Raynal <miquel.raynal@bootlin.com>
> > @@ -25019,21 +25027,6 @@ F:     include/uapi/linux/vsockmon.h
> >  F:     net/vmw_vsock/
> >  F:     tools/testing/vsock/
> >
> > -VMA
> > -M:     Andrew Morton <akpm@linux-foundation.org>
> > -M:     Liam R. Howlett <Liam.Howlett@oracle.com>
> > -M:     Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > -R:     Vlastimil Babka <vbabka@suse.cz>
> > -R:     Jann Horn <jannh@google.com>
> > -L:     linux-mm@kvack.org
> > -S:     Maintained
> > -W:     https://www.linux-mm.org
> > -T:     git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > -F:     mm/vma.c
> > -F:     mm/vma.h
> > -F:     mm/vma_internal.h
> > -F:     tools/testing/vma/
> > -
> >  VMALLOC
> >  M:     Andrew Morton <akpm@linux-foundation.org>
> >  R:     Uladzislau Rezki <urezki@gmail.com>
> > --
> > 2.47.1
> >
> >