From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Jann Horn <jannh@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MAINTAINERS: group all VMA-related files into the VMA section
Date: Mon, 9 Dec 2024 14:11:26 +0000 [thread overview]
Message-ID: <71beb3d1-21ac-4037-8363-6484c0c333b8@lucifer.local> (raw)
In-Reply-To: <1e4c3e31-ea9a-4af4-83f9-15a882732e69@redhat.com>
On Mon, Dec 09, 2024 at 03:00:08PM +0100, David Hildenbrand wrote:
> On 09.12.24 14:25, Vlastimil Babka wrote:
> > On 12/9/24 10:16, David Hildenbrand wrote:
> > > On 06.12.24 20:16, Lorenzo Stoakes wrote:
> > > > There are a number of means of interacting with VMA operations within mm,
> > > > and we have on occasion not been made aware of impactful changes due to
> > > > these sitting in different files, most recently in [0].
> > > >
> > > > Correct this by bringing all VMA operations under the same section in
> > > > MAINTAINERS. Additionally take the opportunity to combine MEMORY MAPPING
> > > > with VMA as there needn't be two entries as they amount to the same thing.
> > > >
> > > > [0]:https://lore.kernel.org/linux-mm/CAG48ez0siYGB8GP5+Szgj2ovBZAkL6Zi4n6GUAjzzjFV9LTkRQ@mail.gmail.com/
> > > >
> > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > > ---
> > > > MAINTAINERS | 19 +++++++------------
> > > > 1 file changed, 7 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index 1e930c7a58b1..95db20c26f5f 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -15060,18 +15060,6 @@ F: tools/mm/
> > > > F: tools/testing/selftests/mm/
> > > > N: include/linux/page[-_]*
> > > >
> > > > -MEMORY MAPPING
> > > > -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: http://www.linux-mm.org
> > > > -T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > > > -F: mm/mmap.c
> > > > -
> > > > MEMORY TECHNOLOGY DEVICES (MTD)
> > > > M: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > M: Richard Weinberger <richard@nod.at>
> > > > @@ -25028,6 +25016,13 @@ 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/madvise.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
> > >
> > > Not sure about mprotect.c, mlock.c and madvise.c, though. I'd claim that
> > > the real "magic" they perform is in page table handling and not
> > > primarily VMA handling (yes, both do VMA changes, but they are the
> > > "easy" part ;) ).
> >
> > I'd think that moving vma files into MEMORY MAPPING (and not the other way)
> > would result in a better overal name, that would be a better fit for the
> > newly added files too?
>
> Maybe. I think vma.c should likely have a different set of maintainers than
> madvise.c and mprotect.c. (again, the magic is in page table modifications)
The bulk of the logic in mremap.c is related to page tables so by this
logic then, that is out too, right?
>
> --
> Cheers,
>
> David / dhildenb
>
next prev parent reply other threads:[~2024-12-09 14:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 19:16 Lorenzo Stoakes
2024-12-06 19:35 ` Liam R. Howlett
2024-12-09 9:16 ` David Hildenbrand
2024-12-09 10:06 ` Lorenzo Stoakes
2024-12-09 14:09 ` David Hildenbrand
2024-12-09 14:28 ` Lorenzo Stoakes
2024-12-09 14:56 ` David Hildenbrand
2024-12-09 15:04 ` Lorenzo Stoakes
2024-12-09 13:25 ` Vlastimil Babka
2024-12-09 14:00 ` David Hildenbrand
2024-12-09 14:11 ` Lorenzo Stoakes [this message]
2024-12-09 14:25 ` David Hildenbrand
2024-12-09 14:38 ` Jann Horn
2024-12-09 14:44 ` David Hildenbrand
2024-12-09 14:45 ` Lorenzo Stoakes
2024-12-09 15:03 ` David Hildenbrand
2024-12-09 15:16 ` Lorenzo Stoakes
2024-12-09 22:02 ` David Hildenbrand
2024-12-10 9:51 ` Lorenzo Stoakes
2024-12-10 16:59 ` David Hildenbrand
2024-12-11 9:35 ` Lorenzo Stoakes
2024-12-11 10:27 ` David Hildenbrand
2024-12-11 10:44 ` Lorenzo Stoakes
2024-12-10 16:06 ` Liam R. Howlett
2024-12-09 14:32 ` Lorenzo Stoakes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=71beb3d1-21ac-4037-8363-6484c0c333b8@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox