linux-kernel - Re: [PATCH] Revert "mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b64f1627-0627-4e4a-b547-5e54167f318e@kernel.org>
Date: Thu, 4 Dec 2025 23:12:06 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>,
 Shuah Khan <skhan@...uxfoundation.org>
Cc: 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, rppt@...nel.org, 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"

On 12/4/25 22:57, Andrew Morton wrote:
> On Wed,  3 Dec 2025 19:33:56 -0700 Shuah Khan <skhan@...uxfoundation.org> wrote:
> 
>> This reverts commit 39231e8d6ba7f794b566fd91ebd88c0834a23b98.
>>
>> Enabling HAVE_GIGANTIC_FOLIOS broke kernel build and git clone on two
>> systems. git fetch-pack fails when cloning large repos and make hangs
>> or errors out of Makefile.build with Error: 139. These failures are
>> random with git clone failing after fetching 1% of the objects, and
>> make hangs while compiling random files.
>>
>> The blow is is one of the git clone failures:
>>
>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux_6.19
>> Cloning into 'linux_6.19'...
>> remote: Enumerating objects: 11173575, done.
>> remote: Counting objects: 100% (785/785), done.
>> remote: Compressing objects: 100% (373/373), done.
>> remote: Total 11173575 (delta 534), reused 505 (delta 411), pack-reused 11172790 (from 1)
>> Receiving objects: 100% (11173575/11173575), 3.00 GiB | 7.08 MiB/s, done.
>> Resolving deltas: 100% (9195212/9195212), done.
>> fatal: did not receive expected object 0002003e951b5057c16de5a39140abcbf6e44e50
>> fatal: fetch-pack: invalid index-pack output
> 
> 39231e8d6ba7 simply shuffles ifdefs and Kconfig items, so I assume it
> exposed a pre-existing bug.
> 
> Reverting 39231e8d6ba7 will re-hide that bug.
> 
> 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?

I have so far no indication that this patch here would change anything 
relevant to the problem we are seeing, all it does is changing 
MAX_FOLIO_ORDER that does not affect any logic we would really care 
about here (safety checks and snapshot_page()).

Can we please wait a bit so we have confirmation that it's not a 
leftover from the huge-zero-folio thingy or something different?

As Mike reports, he found ways to reproduce something similar even with 
39231e8d6ba7 reverted.

-- 
Cheers

David