[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOUHufb3dML6mdySFyaoiaxVfLzGAG8EetP880h2JZTMKm3hDQ@mail.gmail.com>
Date: Fri, 13 Dec 2024 02:36:19 -0700
From: Yu Zhao <yuzhao@...gle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Jeff Xu <jeffxu@...omium.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>, Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
David Hildenbrand <david@...hat.com>
Subject: Re: [PATCH] MAINTAINERS: update MEMORY MAPPING section
On Fri, Dec 13, 2024 at 2:18 AM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
>
> On Thu, Dec 12, 2024 at 10:50:19PM -0700, Yu Zhao wrote:
> > On Wed, Dec 11, 2024 at 11:57 AM Lorenzo Stoakes
> > <lorenzo.stoakes@...cle.com> wrote:
> > >
> > > On Wed, Dec 11, 2024 at 10:36:42AM -0800, Jeff Xu wrote:
> > > > On Wed, Dec 11, 2024 at 2:53 AM Lorenzo Stoakes
> > > > <lorenzo.stoakes@...cle.com> wrote:
> > > > >
> > > > > Update the MEMORY MAPPING section to contain VMA logic as it makes no
> > > > > sense to have these two sections separate.
> > > > >
> > > > > Additionally, add files which permit changes to the attributes and/or
> > > > > ranges spanned by memory mappings, in essence anything which might alter
> > > > > the output of /proc/$pid/[s]maps.
> > > > >
> > > > > This is necessarily fuzzy, as there is not quite as good separation of
> > > > > concerns as we would ideally like in the kernel. However each of these
> > > > > files interacts with the VMA and memory mapping logic in such a way as to
> > > > > be inseparatable from it, and it is important that they are maintained in
> > > > > conjunction with it.
> > > > >
> > > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> > > > > ---
> > > > > MAINTAINERS | 23 ++++++++---------------
> > > > > 1 file changed, 8 insertions(+), 15 deletions(-)
> > > > >
> > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > index 68d825a4c69c..fb91389addd7 100644
> > > > > --- a/MAINTAINERS
> > > > > +++ b/MAINTAINERS
> > > > > @@ -15071,7 +15071,15 @@ L: linux-mm@...ck.org
> > > > > S: Maintained
> > > > > W: http://www.linux-mm.org
> > > > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > > > > +F: mm/mlock.c
> > > > > F: mm/mmap.c
> > > > > +F: mm/mprotect.c
> > > > > +F: mm/mremap.c
> > > > > +F: mm/mseal.c
> > > > > +F: mm/vma.c
> > > > > +F: mm/vma.h
> > > > > +F: mm/vma_internal.h
> > > > > +F: tools/testing/vma/
> > > > >
> > > > Will madvise be here too ?
> > >
> > > No. We had a long discussion about this on another version of this patch :)
> > > it's blurry lines but it, in the end, is too much related to things other
> > > than VMA logic.
> > >
> > > We probably need better separation of stuff, but that's another thing...
> > >
> > > > I'd like to be added as a reviewer on mm/mseal.c. Is there any way to
> > > > indicate this from this file ?
> > >
> > > This is something we can consider in the future, sure.
> >
> > What'd be the downsides of having an additional reviewer? Especially
> > the one who wrote the code...
> >
> > > However at this time you have had really significant issues in engaging
> > > with the community on a regular basis
> >
> > I'm not aware that this can disqualify anyone from being a reviewer of
> > a specific file.
> >
> > > so I think the community is unlikely
> > > to be open to this until you have improved in this area.
> >
> > I do not know Jeff personally, but I think the community should make
> > anyone who wants to contribute feel welcome.
>
> This is very unfair.
>
> I have personally spent several hours doing my best to try to provide
> advice and review strictly to help Jeff get series into the kernel, perhaps
> more than anybody else.
>
> My intent throughout has strictly been to HELP Jeff, to both ensure that
> mseal is as good as it can be, and that he can be a productive and
> successful member of the community.
>
> This is, and has always been, my only intent and desire here - so things
> are actually quite entirely the opposite of what you seem to think they
> are.
>
> My point here is solely that this is just an area that he needs to work on
> and I'm not enitrely sure it'd be helpful until he has done so, this is
> all.
Thanks for clarifying. It was just miscommunication.
Powered by blists - more mailing lists