From: Shakeel Butt <shakeel.butt@linux.dev>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
Jann Horn <jannh@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Matthew Wilcox <willy@infradead.org>,
"Paul E . McKenney" <paulmck@kernel.org>,
SeongJae Park <sj@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] MAINTAINERS: add section for locking of mm's and VMAs
Date: Tue, 15 Apr 2025 11:00:52 -0700 [thread overview]
Message-ID: <g6u6f5euahanr5tmhjakxude6eswz6vl245sdzmhsjwv34pz7h@cleoudcjnwfr> (raw)
In-Reply-To: <0e796032-4f6d-4b7c-9ce6-6519f8f245af@lucifer.local>
On Tue, Apr 15, 2025 at 04:43:41PM +0100, Lorenzo Stoakes 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>
> > > ---
> > > 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?
>
> >
> > 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 :),
Thanks Liam. I don't mind an R here if you decide to send a new version.
Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
next prev parent reply other threads:[~2025-04-15 18:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 13:10 [PATCH 0/2] separate out mmap_lock/VMA locking and update MAINTAINERS Lorenzo Stoakes
2025-04-15 13:10 ` [PATCH 1/2] mm: move mmap/vma locking logic into specific files Lorenzo Stoakes
2025-04-15 16:06 ` Suren Baghdasaryan
2025-04-15 16:07 ` Suren Baghdasaryan
2025-04-16 7:32 ` Lorenzo Stoakes
2025-04-15 17:58 ` Paul E. McKenney
2025-04-16 7:31 ` Lorenzo Stoakes
2025-04-16 7:30 ` Lorenzo Stoakes
2025-04-15 13:10 ` [PATCH 2/2] MAINTAINERS: add section for locking of mm's and VMAs Lorenzo Stoakes
2025-04-15 13:25 ` David Hildenbrand
2025-04-16 7:33 ` Lorenzo Stoakes
2025-04-16 8:07 ` David Hildenbrand
2025-04-15 15:37 ` Liam R. Howlett
2025-04-15 15:43 ` Lorenzo Stoakes
2025-04-15 16:14 ` Suren Baghdasaryan
2025-04-16 7:36 ` Lorenzo Stoakes
2025-04-15 18:00 ` Shakeel Butt [this message]
2025-04-16 6:47 ` 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=g6u6f5euahanr5tmhjakxude6eswz6vl245sdzmhsjwv34pz7h@cleoudcjnwfr \
--to=shakeel.butt@linux.dev \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=paulmck@kernel.org \
--cc=sj@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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