linux-kernel - Re: [PATCH v2 0/7] Make core VMA operations internal and testable

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: <8768fe2a-e4f7-4831-b608-cb3d21556534@lucifer.local>
Date: Fri, 19 Jul 2024 11:52:00 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Vlastimil Babka <vbabka@...e.cz>,
        Matthew Wilcox <willy@...radead.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        Eric Biederman <ebiederm@...ssion.com>, Kees Cook <kees@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, SeongJae Park <sj@...nel.org>,
        Shuah Khan <shuah@...nel.org>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        David Gow <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>
Subject: Re: [PATCH v2 0/7] Make core VMA operations internal and testable

On Thu, Jul 11, 2024 at 02:00:15PM GMT, Liam R. Howlett wrote:
> * Andrew Morton <akpm@...ux-foundation.org> [240710 22:54]:
> > On Wed, 10 Jul 2024 20:32:05 +0100 Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> >
> > > On Thu, Jul 04, 2024 at 08:27:55PM GMT, Lorenzo Stoakes wrote:
> > > > There are a number of "core" VMA manipulation functions implemented in
> > > > mm/mmap.c, notably those concerning VMA merging, splitting, modifying,
> > > > expanding and shrinking, which logically don't belong there.
> > > [snip]
> > >
> > > Hi Andrew,
> > >
> > > Wondering if we're good to look at this going to mm-unstable? As this has
> > > had time to settle, and received R-b tags from Liam and Vlasta.
> > >
> > > It'd be good to get it in, as it's kind of inviting merge conflicts
> > > otherwise and be good to get some certainty as to ordering for instance
> > > vs. Liam's upcoming MAP_FIXED series.
> > >
> > > Also I have some further work I'd like to build on this :>)
> >
> > It's really big and it's quite new and it's really late.  I think it best to await the
> > next -rc cycle, see how much grief it all causes.
>
> Yes, this patch set is huge.
>
> It is, however, extremely necessary to get to the point where we can
> test things better than full system tests (and then wait for a distro to
> rebuild all their rpms and find a missed issue).  I know a lot of people
> would rather see everything in a kunit test, but the reality is that, at
> this level in the kernel, we cannot test as well as we can with the
> userspace approach.
>
> With the scope of the change, it will be a lot of work to develop in
> parallel and rebase on top of the moving of this code.  I'm wondering if
> you can provide some more information on your plan?  Will this be the
> first series in your mm-unstable branch after the release? iow, should I
> be developing on top of the code moving around for my future work?  I am
> happy enough to rebase my in-flight MAP_FIXED patches on top of this set
> if that helps things along.
>
> Thanks,
> Liam

Thanks Liam!

I think best way forward unless you feel we should take a different
approach Andrew is for me to simply wait until the end of the merge window
and at the start of the week after rebase on 6.11-rc1 and do a resend?