linux-kernel - Re: Linux 6.18 amdgpu build error

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: <CAHk-=whd-k3GhNGvVmP7W2p1d0d4ctqJ8iCuG8DbyKzgNqCL+g@mail.gmail.com>
Date: Thu, 4 Dec 2025 11:36:33 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Shuah Khan <skhan@...uxfoundation.org>
Cc: "David Hildenbrand (Red Hat)" <david@...nel.org>, akpm@...ux-foundation.org, 
	Alexander Deucher <Alexander.Deucher@....com>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, amd-gfx@...ts.freedesktop.org, 
	dri-devel <dri-devel@...ts.freedesktop.org>, Guenter Roeck <linux@...ck-us.net>, 
	Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: Linux 6.18 amdgpu build error

On Thu, 4 Dec 2025 at 09:40, Shuah Khan <skhan@...uxfoundation.org> wrote:
>
> This commit has impact on all architectures, not a narrow scoped
> powerpc only thing -  it enables HAVE_GIGANTIC_FOLIOS on x86_64
> and changes the common code that determines MAX_FOLIO_ORDER in
> include/linux/mm.h

So I suspect your bisection might not have worked out, and there might
be two different things going on.

In particular, hugepages were broken in 6.18-rc6 due to commit
adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero
folio").

That was then fixed for rc7 (and obviously final 6.18) by commit
5bebe8de19264 ("mm/huge_memory: Fix initialization of huge zero
folio"), but the breakage up until that time was a bit random.

End result: if you ever ended up bisecting into that broken range
between those two commits, you would get failures on some loads (but
not reliably), and your bisection would end up pointing to some random
thing.

But as mentioned, that particular problem would have been fixed in rc7
and in final 6.18, so any issues you saw with the final build would
have been due to something else.

Can I ask you to try to re-do the bisection, but with that commit
5bebe8de19264 applied by hand - if it wasn't already there - every
time you build a kernel that has adfb6609c680?

That way the bisection wouldn't be affected by that other known bug.

                    Linus