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 1A0192BF3E2 for ; Wed, 19 Nov 2025 12:01:20 +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=1763553681; cv=none; b=mT0H/J0hNj5xJVwtNIF8wir40ZM1lc/4YvKNj3F8kYH3RMx5O9eEl4yUdrb7tZRabxsC/sJji58+e4v2Gtsb42AOEqI4Ino34ALOUI3WydK1IunLNCHIR9dflpwxgZl4TRQkSm44eiBnjBjtW+fxYb5DU9RejhpcKM4I+lRhQY4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763553681; c=relaxed/simple; bh=NBN43WSpMUjrPKe24CxLlKP00e1ShKXYCDpab+ap5g0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tffNZnXERR51CW91GLF+7mx6fKopTp4mHQx7zE+XdFy8a+HgpYWwhgUtnmFwEZlr0j6oYhidTUXnfyW5AbbsKqjUiXpOS1dEN7oGL1XRqWNPMWsHaUjYTnB+YqW1ncA+9FvfO3M5bafNifpfU6j6+4N/5LEMTYD73tLpMVA/XCg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ABpG0vEg; 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="ABpG0vEg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E69AC19425; Wed, 19 Nov 2025 12:01:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763553680; bh=NBN43WSpMUjrPKe24CxLlKP00e1ShKXYCDpab+ap5g0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ABpG0vEgpfMa/usmX5LMvpiNxSDuQE3NQujVblB3GwcZNp3SfzMoVKXpO6KF+TFec SB7030Nn6Kmi43T1ZR6ptm3Ti4APPeQvcAwNMN1+nfRzRwl7i4Q1gDO3EfYrKiNuV5 1GZkxMDxWK78GyiyR7YyctK0Va+MJv9x4YZPI8q+ZgCHpfswwWlq1m3FtGowvTJwjQ QbB8kiVP7GtaEXxgiG7N6aeW3EF9NvbWDv4ja90fgr5ZlL1zcvINPg+IXrrTgGv7/H ZBvX5QFEcdKL+jwm44FgrbdnOwcC4vljiDdmWbKmhid5yblUhERF7wT2Q+vsDPa2Ry 8Y+pAWcSx1jdA== Message-ID: <0f1d7db5-0ca1-4218-95e3-eb3256a5ad65@kernel.org> Date: Wed, 19 Nov 2025 13:01:14 +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: [BUG] General Protection Faults During Git Clone and Kernel Build on Latest Kernel To: Catalin Marinas Cc: "Longia, Amandeep Kaur" , Linux Kernel Mailing List , akpm@linux-foundation.org, lance.yang@linux.dev, will@kernel.org, b-padhi@ti.com, aishwarya.tcv@arm.com, broonie@kernel.org, Raghavendra.KodsaraThimmappa@amd.com, Jan Polensky References: <9401208f-2db1-4397-a615-a03fd7520e53@amd.com> 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 19.11.25 12:58, Catalin Marinas wrote: > On Mon, Nov 17, 2025 at 01:24:43PM +0100, David Hildenbrand (Red Hat) wrote: >> On 17.11.25 13:08, Longia, Amandeep Kaur wrote: >>> Hi all, >>> >>> We've encountered critical issues while running our CI pipeline on the >>> latest kernel (v6.18-rc6), which involves cloning multiple repositories >>> for testing and building the kernel. During this process, we observed >>> two major issues: >> >> Hi, >> >> I observed something similar while testing on Friday between rc4 (good) and >> rc5+ (bad). >> >> I'm sure this it the known issue of adfb6609c6809e107ded9a1cd46f519c882e64ea >> we discussed already here [1]. >> >> >> @Jan, can you send the fix out today? Otherwise I can take care of this so >> we get this fixed asap. >> >> [1] https://lkml.kernel.org/r/20251109003613.1461433-1-japo@linux.ibm.com > > In the worst case, I think Andrew can just revert commit adfb6609c680 > ("mm/huge_memory: initialise the tags of the huge zero folio"), we can > fix it properly with a cc stable afterwards. > > BTW, another quick fix (pretty much what arm64 does when MTE is off): Now fixed upsteam commit 5bebe8de19264946d398ead4e6c20c229454a552 Author: Linus Torvalds Date: Tue Nov 18 08:21:27 2025 -0800 mm/huge_memory: Fix initialization of huge zero folio The recent fix to properly initialize the tags of the huge zero folio had an unfortunate not-so-subtle side effect: it caused the actual *contents* of the huge zero folio to not be initialized at all when the hardware didn't support the memory tagging. The reason was the unfortunate semantics of tag_clear_highpage(): on hardware that didn't do the tagging, it would silently just not do anything at all. And since this is done only on arm64 with MTE support, that basically meant most hardware. It wasn't necessarily immediately obvious since the huge zero page isn't necessarily very heavily used - or because it might already be zero because all-zeroes is the most common pattern. But it ends up causing random odd user space failures when you do hit it. The unfortunate semantics have been around for a while, but became a real bug only when we started actively using __GFP_ZEROTAGS in the generic get_huge_zero_folio() function - before that, it had only ever been used in code that checked that the hardware supported it. Fix this by simply changing the semantics of tag_clear_highpage() to return whether it actually successfully did something or not. While at it, also make it initialize multiple pages in one go, since that's actually what the only caller wants it to do and it simplifies the whole logic. Fixes: adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio") Link: https://lore.kernel.org/all/20251117082023.90176-1-00107082@163.com/ Reviewed-by: David Hildenbrand (Red Hat) Reported-and-tested-by: David Wang <00107082@163.com> Reported-and-tested-by: Carlos Llamas Signed-off-by: Linus Torvalds -- Cheers David