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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <592639a1-fc0d-4a25-a7ff-2a4d1d99d762@lucifer.local>
Date: Tue, 17 Jun 2025 06:19:42 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Pedro Falcato <pfalcato@...e.de>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Jann Horn <jannh@...gle.com>,
        David Hildenbrand <david@...hat.com>,
        Suren Baghdasaryan <surenb@...gle.com>
Subject: Re: [PATCH] MAINTAINERS: add additional mmap-related files to mmap
 section

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@...cle.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@...ck.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