[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]>

Lorenzo Stoakes April 16, 2025, 6:47 a.m. UTC | #6

On Tue, Apr 15, 2025 at 11:00:52AM -0700, Shakeel Butt wrote:
> 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]>

Sure, thanks for volunteering, happy to have you :) am going to do a
respin, will add there.

I believe Jann is currently out, so he can let us know at a later date if
he'd like to be added, I didn't want to presume!

>

Lorenzo Stoakes April 16, 2025, 7:33 a.m. UTC | #7

On Tue, Apr 15, 2025 at 03:25:09PM +0200, David Hildenbrand wrote:
> 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]>

Thanks! Am going to change this to make me and Liam M's so we can provide
back up to Suren when he's on leave, are you fine with propagating this tag
to this also?

Cheers, Lorenzo

>
> --
> Cheers,
>
> David / dhildenb
>

Lorenzo Stoakes April 16, 2025, 7:36 a.m. UTC | #8

On Tue, Apr 15, 2025 at 09:14:47AM -0700, Suren Baghdasaryan wrote:
> 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]>

Thanks!

>
> > > > ---
> > > >  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.

Thanks, will update my and Liam's R's to M's.

David of course will always get my vote but I feel he's far too busy on
this one.

Jann and Vlastimil are also suitable, I believe Jann is away, Vlastimil can
shout if he really wants M but I suspect he's probably fine with the R :>)

>
> >
> > >
> > > 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
> > > >

David Hildenbrand April 16, 2025, 8:07 a.m. UTC | #9

On 16.04.25 09:33, Lorenzo Stoakes wrote:
> On Tue, Apr 15, 2025 at 03:25:09PM +0200, David Hildenbrand wrote:
>> 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]>
> 
> Thanks! Am going to change this to make me and Liam M's so we can provide
> back up to Suren when he's on leave, are you fine with propagating this tag
> to this also?

Yes! Thanks

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]>