[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dc22e2e2-a62b-4b9f-9fb0-f3a42a57b00f@kernel.org>
Date: Fri, 5 Dec 2025 08:05:14 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Mike Rapoport <rppt@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>
Cc: Shuah Khan <skhan@...uxfoundation.org>, maddy@...ux.ibm.com,
mpe@...erman.id.au, npiggin@...il.com, christophe.leroy@...roup.eu,
lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, vbabka@...e.cz,
surenb@...gle.com, mhocko@...e.com, masahiroy@...nel.org,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] Revert "mm: fix MAX_FOLIO_ORDER on powerpc configs with
hugetlb"
>> 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 <skhan@...uxfoundation.org>
>>
>> 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
Powered by blists - more mailing lists