From: Mike Rapoport <rppt@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>,
david@kernel.org, maddy@linux.ibm.com, mpe@ellerman.id.au,
npiggin@gmail.com, christophe.leroy@csgroup.eu,
lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
vbabka@suse.cz, surenb@google.com, mhocko@suse.com,
masahiroy@kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] Revert "mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb"
Date: Fri, 5 Dec 2025 09:01:24 +0200 [thread overview]
Message-ID: <aTKDRF2sMdM_5aRB@kernel.org> (raw)
In-Reply-To: <20251204135746.6d291cc861b4507b1fe95aaa@linux-foundation.org>
On Thu, Dec 04, 2025 at 01:57:46PM -0800, Andrew Morton wrote:
> On Wed, 3 Dec 2025 19:33:56 -0700 Shuah Khan <skhan@linuxfoundation.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.
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 <skhan@linuxfoundation.org>
>
> Let's have a cc:stable here, just to be sure.
... and we can skip all this hassle.
[1] https://lore.kernel.org/all/317deba2-e560-44ed-a9f7-3c6fdc446b6d@linuxfoundation.org
[2] https://lore.kernel.org/linux-mm/aTKAo7JgBX0X_pBl@kernel.org
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-12-05 7:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-04 2:33 Shuah Khan
2025-12-04 6:17 ` David Hildenbrand (Red Hat)
2025-12-04 6:35 ` Mike Rapoport
2025-12-04 17:03 ` Shuah Khan
2025-12-04 19:38 ` David Hildenbrand (Red Hat)
2025-12-04 20:59 ` Mike Rapoport
2025-12-04 21:27 ` Mike Rapoport
2025-12-04 21:57 ` Andrew Morton
2025-12-04 22:12 ` David Hildenbrand (Red Hat)
2025-12-05 7:01 ` Mike Rapoport [this message]
2025-12-05 7:05 ` David Hildenbrand (Red Hat)
2025-12-05 7:41 ` Christophe Leroy (CS GROUP)
2025-12-05 18:19 ` Andrew Morton
2025-12-04 22:16 ` David Hildenbrand (Red Hat)
2025-12-04 23:23 ` Shuah Khan
2025-12-05 6:50 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aTKDRF2sMdM_5aRB@kernel.org \
--to=rppt@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=christophe.leroy@csgroup.eu \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=maddy@linux.ibm.com \
--cc=masahiroy@kernel.org \
--cc=mhocko@suse.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox