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 180221BEF7E; Mon, 4 Aug 2025 00:43:09 +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=1754268189; cv=none; b=mnXGxCJuiPVYTYjEFKzJe40NJBosCns7tzdplFzEjm0KZOemhsQSdviwKU3UoreUtvQQQkgrlgSXu9a5R8dTstFoUfTIcZ5zwxsErOWSI7ngaAAJ49gOy13e3qaaUSSo+7xdvsvcZIV6AF1UbRQKBUSKX+a0jxW/UyElIzLEiBs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754268189; c=relaxed/simple; bh=eZDxEDEU8HOBZc4GN5X5ZfEyoOacYfSvJp1CUBaGIB8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=efXTGjMZIDmKPkR+Nhdsvd3XQQB+G1O2eab1itsU1JIRm7x2JLtPcn1BXEw5+jEM8K5eG94YeJqgodMNRo+uPJYbZD2AN3eW3rjpZZ0AGw0uLME4xnZ8ZawOXd9JxOPTAx92IQChYctwl7x2OIxZAjHeQq9tANnsPm0sUzPZYaI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oBW0AhFA; 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="oBW0AhFA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C9F8C4CEF0; Mon, 4 Aug 2025 00:43:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754268189; bh=eZDxEDEU8HOBZc4GN5X5ZfEyoOacYfSvJp1CUBaGIB8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oBW0AhFAqJVYssfThtvRJPscwHzVWor0AmY8QvI7yDGIjSy+8ROlwjcOCVtoapEms hZ+wQlh2uB/+gr5hMBd/b5su1j2rYjPqg1vm6y7jZEjLBDNyFvoVroPd55kkM7+x43 tUQiDbGUtjkuj5/cErAYNnLwj+9/++FlbI4a+UVXz0nkDJ1jyCNBKehd51aSQltZHl sKCS4IESlxtXSM1tXr0q5TJhKaR9hV9DaQbLI+ua8TKEtknJsKlssErd7wVGcxxdfD B5TJXUvGRwoUHtf2g0Uuu2J0p7SS6NqN+a0HndtPKoEyLubdp5YuR4gMM6PdUa/BkP eMi86pvtedfpw== 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, u.kleine-koenig@baylibre.com, bp@alien8.de, peterz@infradead.org, linux-acpi@vger.kernel.org Subject: [PATCH AUTOSEL 5.4 18/28] ACPI: APEI: GHES: add TAINT_MACHINE_CHECK on GHES panic path Date: Sun, 3 Aug 2025 20:42:17 -0400 Message-Id: <20250804004227.3630243-18-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250804004227.3630243-1-sashal@kernel.org> References: <20250804004227.3630243-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 5.4.296 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 50bed5a70812..d02d7cbab387 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -709,6 +709,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