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

Liam Howlett liam.howlett at oracle.com
Thu May 19 07:56:33 PDT 2022

* 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?  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.

> I see a new version of MGLRU is on the wires so I expect I'll merge
> that in shortly after mapletree, which will muddy the waters somewhat. 
> Maybe a week after, to give mapletree some standalone time.  But MGLRU
> can be disabled at compile time so that's the first question we'll
> ask reporters.

Sounds good.


More information about the maple-tree mailing list