[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.
Thanks,
Liam
More information about the maple-tree
mailing list