Re: [PATCH] MAINTAINERS: add additional mmap-related files to mmap section

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

On Mon, Jun 16, 2025 at 10:04:54PM +0100, Pedro Falcato wrote:
> (adding a few people on CC)
>
> On Mon, Jun 16, 2025 at 09:49:52PM +0100, Pedro Falcato wrote:
> > On Mon, Jun 16, 2025 at 09:35:03PM +0100, Lorenzo Stoakes wrote:
> > > msync and nommu are directly related to memory mapping, memfd and mincore
> > > are less so but are roughly speaking operating on virtual memory mappings
> > > from the point of view of the user so this seems the most appropriate place
> > > for them.
> > >
> > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > ---
> > >  MAINTAINERS | 6 +++++-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 4523a6409186..a5d1ff923a62 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -15735,7 +15735,6 @@ F:	Documentation/admin-guide/mm/
> > >  F:	Documentation/mm/
> > >  F:	include/linux/gfp.h
> > >  F:	include/linux/gfp_types.h
> > > -F:	include/linux/memfd.h
> > >  F:	include/linux/memory_hotplug.h
> > >  F:	include/linux/memory-tiers.h
> > >  F:	include/linux/mempolicy.h
> > > @@ -15974,12 +15973,17 @@ 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:	include/linux/memfd.h
> > >  F:	include/trace/events/mmap.h
> > > +F:	mm/memfd.c
> >
> > memfd is a big stretch, no? I think it would feel more at home with shmem, or even VFS people.

Ack agreed, will move over to shmem.

> >
> > > +F:	mm/mincore.c
> > >  F:	mm/mlock.c
> > >  F:	mm/mmap.c
> > >  F:	mm/mprotect.c
> > >  F:	mm/mremap.c
> > >  F:	mm/mseal.c
> > > +F:	mm/msync.c
> > > +F:	mm/nommu.c
> > >  F:	mm/vma.c
> > >  F:	mm/vma.h
> > >  F:	mm/vma_exec.c
> >
> > the rest obviously LGTM.
> >
>
> This reminds me: now that we're at it, could we cross-own madvise.c? Now that
> we know it can be done. It's the only mmap-related syscall (i think?) we're
> missing.

This is already owned explicitly by MEMORY MAPPING - MADVISE (MEMORY ADVICE)

IT was separated out on purpose so David could have M without having to M
the rest.

>
> Also possibly mmap_lock.c.

This is explicitly separated out in to MEMORY MAPPING - LOCKING for similar
reasons.

>
> --
> Pedro