| Message ID | 0722c3fe0cb4c1e54ce01c7689ce4615ecc87e16.1744720574.git.lorenzo.stoakes@oracle.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | separate out mmap_lock/VMA locking and update MAINTAINERS | expand |
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 <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 > + > MEMORY MAPPING - MADVISE (MEMORY ADVICE) > M: Andrew Morton <akpm@linux-foundation.org> > M: Liam R. Howlett <Liam.Howlett@oracle.com> Sounds like a good idea to me Acked-by: David Hildenbrand <david@redhat.com>
* 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? 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 <akpm@linux-foundation.org> > M: Liam R. Howlett <Liam.Howlett@oracle.com> > -- > 2.49.0 >
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 :), 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 <akpm@linux-foundation.org> > > M: Liam R. Howlett <Liam.Howlett@oracle.com> > > -- > > 2.49.0 > >
On Tue, Apr 15, 2025 at 8:43 AM Lorenzo Stoakes <lorenzo.stoakes@oracle.com> 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> Reviewed-by: Suren Baghdasaryan <surenb@google.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? 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 <akpm@linux-foundation.org> > > > M: Liam R. Howlett <Liam.Howlett@oracle.com> > > > -- > > > 2.49.0 > > >
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>
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 <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> 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! >
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 <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 > > + > > MEMORY MAPPING - MADVISE (MEMORY ADVICE) > > M: Andrew Morton <akpm@linux-foundation.org> > > M: Liam R. Howlett <Liam.Howlett@oracle.com> > > Sounds like a good idea to me > > Acked-by: David Hildenbrand <david@redhat.com> 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 >
On Tue, Apr 15, 2025 at 09:14:47AM -0700, Suren Baghdasaryan wrote: > On Tue, Apr 15, 2025 at 8:43 AM Lorenzo Stoakes > <lorenzo.stoakes@oracle.com> 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> > > Reviewed-by: Suren Baghdasaryan <surenb@google.com> 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 <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? > > 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 <akpm@linux-foundation.org> > > > > M: Liam R. Howlett <Liam.Howlett@oracle.com> > > > > -- > > > > 2.49.0 > > > >
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 + MEMORY MAPPING - MADVISE (MEMORY ADVICE) M: Andrew Morton <akpm@linux-foundation.org> M: Liam R. Howlett <Liam.Howlett@oracle.com>
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(+)