On Wed, 3 Dec 2025 19:33:56 -0700 Shuah Khan <[email protected]> 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? > Signed-off-by: Shuah Khan <[email protected]> Let's have a cc:stable here, just to be sure.
