* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> [240710 22:54]: > On Wed, 10 Jul 2024 20:32:05 +0100 Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> 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
