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 87E7629A2; Mon, 4 Aug 2025 00:25:56 +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=1754267156; cv=none; b=AHNq4+Rtq0Dzhen18dbm/XojK6DXkm55/IdeC//i33qQB9+P05+qllv1JFQZvzsXUTNfP6ytN2EJNfaQB6+6ez0932oI1ELudmG3y1XErzT+VhrDIuWQBHuURa+Bh+Kn/nJVW5hjY/Odf9NJHZXpgXGTGElD7ZPX83O9j3DKZuc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754267156; c=relaxed/simple; bh=VrHrl1OyVIYZ/kAm3OW6zJXl6SIGsW6QETUiRfTi5dI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=kLc8qD90O6M65XJJ4R8HYeKUdeg95VDeCoAV1tFXHwai5I7pof3g/AXdE5vPUzfSrOhD0jxQwkdPLJ0n7kjn0MZtn3Xn2/1atrgkJiEnwB4MhkQR5Hd1vWD3Ieyu1gyMqMDA0HWTmW53yuP4OV7hl5UPBY7+bc4CEtYL7FPG+O0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=enK1i2hZ; 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="enK1i2hZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F34DFC4CEEB; Mon, 4 Aug 2025 00:25:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754267156; bh=VrHrl1OyVIYZ/kAm3OW6zJXl6SIGsW6QETUiRfTi5dI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=enK1i2hZNZWfxoctznup3gVRBo5vbWTvLz7p2yYjc9BjRxJfS+ms3YW+2Hh4YOFWu SofVKeHOK/Piubh6zKN7JAaHfJ6PXtURx3+SbqOm5tiyyBfmG48EAd2cBOwAdS9Tmx 8BgIGKi8DyJEj6pQ6/hfRhACPiTP6f0Czpzhd66tXVPK9NvD4r4U/MxITL0GufdzGs af33dYblpZq4PZSq2ivlH67MyrhyLQk31nYqg1Tm7iUfdIAlA0i6mYTmJNmOKK1E/J Yn9FG+ezYFWKyeW2LBlv+IBvQwDv1ozWYtYyWr0Ok7L31LDLjpQfOtiEUSnvFpErcu cJRDIUTRGs1FA== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Breno Leitao , Tony Luck , "Rafael J . Wysocki" , Sasha Levin , rafael@kernel.org, dave.jiang@intel.com, ira.weiny@intel.com, xueshuai@linux.alibaba.com, Smita.KoralahalliChannabasappa@amd.com, mingo@kernel.org, quic_hyiwei@quicinc.com, bp@alien8.de, peterz@infradead.org, linux-acpi@vger.kernel.org Subject: [PATCH AUTOSEL 6.16 48/85] ACPI: APEI: GHES: add TAINT_MACHINE_CHECK on GHES panic path Date: Sun, 3 Aug 2025 20:22:57 -0400 Message-Id: <20250804002335.3613254-48-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250804002335.3613254-1-sashal@kernel.org> References: <20250804002335.3613254-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.16 Content-Transfer-Encoding: 8bit From: Breno Leitao [ Upstream commit 4734c8b46b901cff2feda8b82abc710b65dc31c1 ] When a GHES (Generic Hardware Error Source) triggers a panic, add the TAINT_MACHINE_CHECK taint flag to the kernel. This explicitly marks the kernel as tainted due to a machine check event, improving diagnostics and post-mortem analysis. The taint is set with LOCKDEP_STILL_OK to indicate lockdep remains valid. At large scale deployment, this helps to quickly determine panics that are coming due to hardware failures. Signed-off-by: Breno Leitao Reviewed-by: Tony Luck Link: https://patch.msgid.link/20250702-add_tain-v1-1-9187b10914b9@debian.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Based on my analysis of this commit, here is my assessment: **Backport Status: YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Fixes a real diagnostic issue**: The commit adds the TAINT_MACHINE_CHECK flag when GHES (Generic Hardware Error Source) triggers a panic. This is important for post-mortem analysis at scale, as explicitly stated in the commit message: "At large scale deployment, this helps to quickly determine panics that are coming due to hardware failures." 2. **Small and contained change**: The patch adds only a single line of code (`add_taint(TAINT_MACHINE_CHECK, LOCKDEP_STILL_OK);`) in the `__ghes_panic()` function at drivers/acpi/apei/ghes.c:1091. This meets the stable kernel rule of being under 100 lines. 3. **Obviously correct**: The change follows established kernel patterns. Looking at the grep results, other machine check handlers already use this same pattern: - arch/x86/kernel/cpu/mce/core.c:1640 - arch/powerpc/kernel/mce.c:332 - arch/x86/kernel/cpu/mce/p5.c:40 - arch/x86/kernel/cpu/mce/winchip.c:24 4. **No architectural changes**: This is purely a diagnostic improvement that adds taint information without changing any functionality or behavior of the GHES panic path. 5. **Minimal risk**: The change uses LOCKDEP_STILL_OK flag, indicating that lockdep remains valid after the taint, which is the safer option compared to LOCKDEP_NOW_UNRELIABLE used in some other machine check paths. 6. **Real benefit for users**: For organizations running Linux at scale, being able to quickly identify hardware-related panics through the taint flag provides significant operational value for triaging issues. The commit meets all the stable kernel criteria: it's small, obviously correct, fixes a real diagnostic limitation that affects users (especially at scale), and has been reviewed by Tony Luck who is a recognized maintainer in the RAS (Reliability, Availability, and Serviceability) subsystem. drivers/acpi/apei/ghes.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 281a0a2f6730..bda33a0f0a01 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -1099,6 +1099,8 @@ static void __ghes_panic(struct ghes *ghes, __ghes_print_estatus(KERN_EMERG, ghes->generic, estatus); + add_taint(TAINT_MACHINE_CHECK, LOCKDEP_STILL_OK); + ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx); if (!panic_timeout) -- 2.39.5