linux-kernel - Re: [PATCH] MAINTAINERS: update MEMORY MAPPING section

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOUHufYCF0i_aJZPceMXfcTZUcZsCY9fBuMr=25q1bROWx5nsg@mail.gmail.com>
Date: Thu, 12 Dec 2024 22:50:19 -0700
From: Yu Zhao <yuzhao@...gle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Andrew Morton <akpm@...ux-foundation.org>
Cc: 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 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.

> You will, of course, remain cc'd on any mseal changes regardless, so
> functionally nothing will differ.
>
> And equally, this change doesn't alter my or Liam's role, we will apply the
> same review regardless.
>
> The purpose of this change is, as the message says, to ensure the integrity
> and maintainership of logic relating to memory mapping, and mseal is really
> entirely a VMA operation so has to be included as a result.
>
> So it is administrative in nature, ultimately.

Sorry -- I couldn't make out what you are trying to say here. So I'd
like to ask bluntly: is there any previous disagreement between you
and Jeff to make you reject his request? If so, I think we'd need a
3rd party (probably Andrew) to review his request. If not, I'd urge
you to use his help.