[PATCH] maple_tree: Fix mas_next() when already on the last node entry

[Andrew Morton]

On Thu, 19 May 2022 14:56:33 +0000 Liam Howlett <liam.howlett at oracle.com> wrote:

> * Andrew Morton <akpm at linux-foundation.org> [220517 22:05]:
> > On Tue, 17 May 2022 20:07:25 +0000 Liam Howlett <liam.howlett at oracle.com> wrote:
> > 
> > > > > However, as Heiko already wrote in another mail i would also like to
> > > > > request that the maple tree code isn't merged with the next merge
> > > > > window. These patches touch a lot of critical infrastructure, and i would like
> > > > > to have it in next for at least one development cycle, so we can be sure
> > > > > that we've seen and fixed most of the issues.
> > > > 
> > > > Agree, it isn't looking good.  If Linus does an -rc8 (unlikely) then
> > > > perhaps we'll be in better shape.
> > > > 
> > > 
> > > Yeah, it needs more soak time.  I've been testing on a lot of platforms
> > > and have a number of testcases, but it's difficult to cover this
> > > critical infrastructure with the variations of hardware and
> > > randomization of addresses.
> > 
> > I think we're pretty close.  Asymptotically speaking ;) I expect an
> > additional week would get us there but alas, we won't have it.
> > 
> > I've disabled the mapletree patches for now, so that Yang Shi's "Make
> > khugepaged collapse readonly FS THP more consistent" series can get a
> > run without mapletree possibly affecting its behaviour.  That's all
> > pushed out now.
> > 
> > This involved switching the order of the two series.  I think I screwed
> > that up last time so now I diffed all the dang files to ensure that the
> > end result was the same.  No more stray khugepaged_enter_vma_merge()s
> > hanging around.
> > 
> > I plan to bring back the current mapletree series once we're merged up
> > with Linus.  Or maybe you'd prefer to start afresh with a new series
> > (based on current mm-unstable, please).
> > 
> > New versions of patchsets worry me.  Sometimes I retain all the -fix
> > patches I've accumulated, check that they're all incorporated in the
> > new version.  Other times I'll diff the old and new trees, check that
> > any differences were intentional as per the changelogs.  Neither of
> > these approaches catches missed changelog updates.
> 
> I'm not sure I have all your changelog updates - I believe you added
> some of my emailed comments that you deemed important.  On that note it
> may be better to keep them on your side, unless you have a git branch
> or tag with the changelogs incorporated?

git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm tag
mm-everything-2022-05-17-20-17 is up to date with mapletree changelogs. 
But if poss, I'd prefer to keep dribbling the fixes on top of what's
here.  But it's not a problem if drop-and-redo is preferabe.

>  I do have a few more patches
> resulting from my sparc64 testing that I should also send to add to your
> list.  There is also some cleanup left to do in the maple tree code
> itself, so that'll be another patch.

Cool.