On Thu, Dec 04, 2025 at 01:57:46PM -0800, Andrew Morton wrote:
> 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.
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].
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.
[1]
https://lore.kernel.org/all/[email protected]
[2] https://lore.kernel.org/linux-mm/[email protected]
--
Sincerely yours,
Mike.
