From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABCA3398F8A for ; Thu, 4 Dec 2025 19:46:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764877567; cv=none; b=ePdTleS001g21bK9NfPQ56SsMCjAhba9+JxCA7WZlEWXCekb4jBiLVaxCkMPCRhDPSg97z9s+aipm/JHWRt9oylyufdUHVgLn4pvNNVoKvReunib5/KdXIX+ug6fnbL1AT+d7DziiDeDAafUcCYhGh9ylHhU65hGGLBU8ylAUX4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764877567; c=relaxed/simple; bh=aAQKSi8xzvUmhLEEthsE7YsJaouU3OspVMzy9V0zWPI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kgAQVBBL6AwpmyZaaLKtfP0zvG3SXjDZcSBcFqEIlx42jAOBCCSDaJG5Uy9RNhkaNMznqpn3MHsL9RkHmI708CtNB+cJp08rLWuom9Bd2OQlVyfVFcC9gKdLIFZ9vG/CmOiqW475dn/oH9IcWpH3J53Zp5yg1oumcT41Ry3hIt4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V0YcaQMn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V0YcaQMn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D420FC4CEFB; Thu, 4 Dec 2025 19:46:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764877564; bh=aAQKSi8xzvUmhLEEthsE7YsJaouU3OspVMzy9V0zWPI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=V0YcaQMnxiALXGBfC3zNhbc2oxyhQb3smPyeGa+JMOeyLDKFI6y9TIgsdJebP6Qbz wx3MLprCjRwfVB+0C/WWZ7ygO0l6Dc9MNaCJTlWDGQY1qIXXzPjofAF7DdLDEzGelg pbnbIiG7Wp1PAW/tPldpQgQB+FTxkkNF7T01gQeIdn63Ukr4Np1dWDrhnKQBEX/c4z 8ySXQTTmymw4v0S5kC2PPhgX2s8irgYgcWEEdWmXNxNCJFw+pygoyBwjNo3vAK0Hiy ORwS3dnZzXUuIKpOuHC2uMIAUUmbzR1DQH9CzKQ/GlLxcVy0krp+BUlpwgFJmEtP7w RDaXycol3+bdQ== Message-ID: <3b6d6e50-91ac-435e-adad-a67d4198a5b5@kernel.org> Date: Thu, 4 Dec 2025 20:45:59 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Linux 6.18 amdgpu build error To: Linus Torvalds , Shuah Khan Cc: akpm@linux-foundation.org, Alexander Deucher , Linux Kernel Mailing List , amd-gfx@lists.freedesktop.org, dri-devel , Guenter Roeck , Linux Memory Management List References: <74032153-813a-4a40-8363-cce264f4d5ea@linuxfoundation.org> <1eb24816-530b-4470-8e58-ce7d8297996c@roeck-us.net> <0425d7b4-76e4-4057-83a5-a7b17a051c54@linuxfoundation.org> <9d520a1d-0b8d-4d30-b29f-230fc0f92b8a@linuxfoundation.org> <1f31b86d-283c-4878-92d0-ab90aed0c58d@roeck-us.net> <5af4522e-30ab-4eec-a861-c2760cdabd4f@linuxfoundation.org> <2bc690ca-fa57-46fa-949b-28b5441cd364@kernel.org> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/4/25 20:36, Linus Torvalds wrote: > On Thu, 4 Dec 2025 at 09:40, Shuah Khan 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? Right, that's what I also proposed in [1]. I cannot make sense of how 39231e8d6ba could possibly trigger it given that it only affects the value of MAX_FOLIO_ORDER --- which is primarily used for safety checks and snapshot_page(), nothing that could explain changed application behavior, really. But while Shuah is retesting, I'll go have a yet another look. [1] https://lore.kernel.org/all/78af7da4-d213-42c6-8ca6-c2bdca81f233@linuxfoundation.org/ -- Cheers David