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] [day] [month] [year] [list]
Message-ID: <62e40a0f-93a1-4b75-b613-e877a12da1bd@lucifer.local>
Date: Fri, 13 Dec 2024 15:19:45 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jeff Xu <jeffxu@...omium.org>
Cc: Yu Zhao <yuzhao@...gle.com>, Andrew Morton <akpm@...ux-foundation.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 07:05:06AM -0800, Jeff Xu wrote:
> Hi Lorenzo
>
> On Fri, Dec 13, 2024 at 1: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.
> >
> Thanks for your help (and others ) on reviewing mseal_test.c.
>

Thanks :)

> For the reference: I sent RFC [1] to follow up on refactor work of
> selftest. To save your review time, I made minimal changes using two
> test cases, and intended as a baseline/pattern for remaining
> refactoring work for mseal_test.c.  If you have time to give your
> comments about the RFC before the holiday break, great! I can start
> refactoring the other mseal_test.  Otherwise, the after-holiday will
> be fine too.
>
> [1] https://lore.kernel.org/all/20241211053311.245636-1-jeffxu@google.com/

Yeah I'm so sorry for not getting to this sooner, that's my bad, got tied up
looking at other things. I will definitely take a look and PLEASE do ping me if
I don't it's no problem.

I do think at this point because I'm off from next Mon it'll be post-xmas, but I
_will_ get to it.

I will do the only completely reliable thing for me re: TODOs, which is to write
it on the whiteboard :P

>
> Best regards,
> -Jeff

Cheers!