[2/2] MAINTAINERS: add section for locking of mm's and VMAs

Commit Message

Lorenzo Stoakes April 15, 2025, 1:10 p.m. UTC

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 <[e-mail]>
---
 MAINTAINERS | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

Comments

David Hildenbrand April 15, 2025, 1:25 p.m. UTC | #1

On 15.04.25 15:10, Lorenzo Stoakes wrote:
> 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 <[e-mail]>
> ---
>   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 <[e-mail]>
> +M:	Suren Baghdasaryan <[e-mail]>
> +R:	Liam R. Howlett <[e-mail]>
> +R:	Lorenzo Stoakes <[e-mail]>
> +R:	Vlastimil Babka <[e-mail]>
> +L:	[e-mail]
> +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
> +
>   MEMORY MAPPING - MADVISE (MEMORY ADVICE)
>   M:	Andrew Morton <[e-mail]>
>   M:	Liam R. Howlett <[e-mail]>

Sounds like a good idea to me

Acked-by: David Hildenbrand <[e-mail]>

Liam R. Howlett April 15, 2025, 3:37 p.m. UTC | #2

* Lorenzo Stoakes <[e-mail]> [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 <[e-mail]>
> ---
>  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 <[e-mail]>
> +M:	Suren Baghdasaryan <[e-mail]>
> +R:	Liam R. Howlett <[e-mail]>
> +R:	Lorenzo Stoakes <[e-mail]>
> +R:	Vlastimil Babka <[e-mail]>
> +L:	[e-mail]
> +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?

Shakeel and/or Jann might be good additions to this list somewhere
(looking at the edits to the file).

> +
>  MEMORY MAPPING - MADVISE (MEMORY ADVICE)
>  M:	Andrew Morton <[e-mail]>
>  M:	Liam R. Howlett <[e-mail]>
> -- 
> 2.49.0
>

Lorenzo Stoakes April 15, 2025, 3:43 p.m. UTC | #3

On Tue, Apr 15, 2025 at 11:37:04AM -0400, Liam R. Howlett wrote:
> * Lorenzo Stoakes <[e-mail]> [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 <[e-mail]>
> > ---
> >  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 <[e-mail]>
> > +M:	Suren Baghdasaryan <[e-mail]>
> > +R:	Liam R. Howlett <[e-mail]>
> > +R:	Lorenzo Stoakes <[e-mail]>
> > +R:	Vlastimil Babka <[e-mail]>
> > +L:	[e-mail]
> > +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 :), though I
_don't think_ either Shakeel or Jann really actively work with mmap/VMA
locks (forgive me if I am mistaken) so wouldn't really be suitable for M as
I feel that requires some active development.

>
> > +
> >  MEMORY MAPPING - MADVISE (MEMORY ADVICE)
> >  M:	Andrew Morton <[e-mail]>
> >  M:	Liam R. Howlett <[e-mail]>
> > --
> > 2.49.0
> >

Suren Baghdasaryan April 15, 2025, 4:14 p.m. UTC | #4

On Tue, Apr 15, 2025 at 8:43 AM Lorenzo Stoakes
<[e-mail]> wrote:
>
> On Tue, Apr 15, 2025 at 11:37:04AM -0400, Liam R. Howlett wrote:
> > * Lorenzo Stoakes <[e-mail]> [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 <[e-mail]>

Reviewed-by: Suren Baghdasaryan <[e-mail]>

> > > ---
> > >  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 <[e-mail]>
> > > +M: Suren Baghdasaryan <[e-mail]>
> > > +R: Liam R. Howlett <[e-mail]>
> > > +R: Lorenzo Stoakes <[e-mail]>
> > > +R: Vlastimil Babka <[e-mail]>
> > > +L: [e-mail]
> > > +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?

Thanks for trusting me with the maintenance. I'll do my best not to betray it.
I agree that you and Liam have reviewed this code enough times to make
informed decisions. Other good candidates include Jann and Vlastimil.
David already reviews the entire mm codebase, so adding him is
probably unnecessary.

>
> >
> > 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 :), though I
> _don't think_ either Shakeel or Jann really actively work with mmap/VMA
> locks (forgive me if I am mistaken) so wouldn't really be suitable for M as
> I feel that requires some active development.
>
> >
> > > +
> > >  MEMORY MAPPING - MADVISE (MEMORY ADVICE)
> > >  M: Andrew Morton <[e-mail]>
> > >  M: Liam R. Howlett <[e-mail]>
> > > --
> > > 2.49.0
> > >

Shakeel Butt April 15, 2025, 6 p.m. UTC | #5

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 <[e-mail]> [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 <[e-mail]>
> > > ---
> > >  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 <[e-mail]>
> > > +M:	Suren Baghdasaryan <[e-mail]>
> > > +R:	Liam R. Howlett <[e-mail]>
> > > +R:	Lorenzo Stoakes <[e-mail]>
> > > +R:	Vlastimil Babka <[e-mail]>
> > > +L:	[e-mail]
> > > +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 <[e-mail]>

Patch

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 <[e-mail]>
+M:	Suren Baghdasaryan <[e-mail]>
+R:	Liam R. Howlett <[e-mail]>
+R:	Lorenzo Stoakes <[e-mail]>
+R:	Vlastimil Babka <[e-mail]>
+L:	[e-mail]
+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
+
 MEMORY MAPPING - MADVISE (MEMORY ADVICE)
 M:	Andrew Morton <[e-mail]>
 M:	Liam R. Howlett <[e-mail]>