39231e8d6ba7 simply shuffles ifdefs and Kconfig items, so I assume it
exposed a pre-existing bug.
Reverting 39231e8d6ba7 will re-hide that bug.
Shuah confirmed that the bugs were on v6.18-rc6 and they were fixed in
6.18 [1].
I verified that reverting 39231e8d6ba7 from v6.18-rc6 does not solve
anything, but applying 5bebe8de19264 does [2].
Thanks!
So reverting 39231e8d6ba7 does not change anything and there is no bug it
hides. The bug was introduced by adfb6609c680 ("mm/huge_memory: initialise
the tags of the huge zero folio"), was fixed by 5bebe8de1926
("mm/huge_memory: Fix initialization of huge zero folio") ...
And that isn't a bad thing. If we re-hide the bug in 6.18.x and in
mainline then that relieves the people who are hitting this and it
takes the pressure off David, Mike and yourself to get the underlying
bug fixed in a hurry.
So I think I'll queue this as a hotfix, plan to send it Linuswards in a
couple of days.
Or Linus may choose to apply it directly or to do a local revert of
39231e8d6ba7. But I don't see how a local revert will get communicated
to the 6.18.x maintainers.
David, Linus, opinions please?
Signed-off-by: Shuah Khan <[email protected]>
Let's have a cc:stable here, just to be sure.
... and we can skip all this hassle.
Yes.
Thinking about reverting arbitrary commits after Shuah clearly tested
something wrong is completely unreasonable.
--
Cheers
David
