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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Thu, Jul 11, 2024 at 02:00:15PM GMT, Liam R. Howlett wrote:
> * Andrew Morton <akpm@linux-foundation.org> [240710 22:54]:
> > On Wed, 10 Jul 2024 20:32:05 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.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?