linux-kernel - [PATCH AUTOSEL 6.12 054/107] drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241124133301.3341829-54-sashal@kernel.org>
Date: Sun, 24 Nov 2024 08:29:14 -0500
From: Sasha Levin <sashal@...nel.org>
To: linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Cc: Badal Nilawar <badal.nilawar@...el.com>,
	Matthew Brost <matthew.brost@...el.com>,
	Matthew Auld <matthew.auld@...el.com>,
	John Harrison <John.C.Harrison@...el.com>,
	Himal Prasad Ghimiray <himal.prasad.ghimiray@...el.com>,
	Sasha Levin <sashal@...nel.org>,
	lucas.demarchi@...el.com,
	thomas.hellstrom@...ux.intel.com,
	rodrigo.vivi@...el.com,
	maarten.lankhorst@...ux.intel.com,
	mripard@...nel.org,
	tzimmermann@...e.de,
	airlied@...il.com,
	simona@...ll.ch,
	intel-xe@...ts.freedesktop.org,
	dri-devel@...ts.freedesktop.org
Subject: [PATCH AUTOSEL 6.12 054/107] drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout

From: Badal Nilawar <badal.nilawar@...el.com>

[ Upstream commit e5152723380404acb8175e0777b1cea57f319a01 ]

In case if g2h worker doesn't get opportunity to within specified
timeout delay then flush the g2h worker explicitly.

v2:
  - Describe change in the comment and add TODO (Matt B/John H)
  - Add xe_gt_warn on fence done after G2H flush (John H)
v3:
  - Updated the comment with root cause
  - Clean up xe_gt_warn message (John H)

Closes: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1620
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2902
Signed-off-by: Badal Nilawar <badal.nilawar@...el.com>
Cc: Matthew Brost <matthew.brost@...el.com>
Cc: Matthew Auld <matthew.auld@...el.com>
Cc: John Harrison <John.C.Harrison@...el.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@...el.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@...el.com>
Acked-by: Matthew Brost <matthew.brost@...el.com>
Signed-off-by: Matthew Brost <matthew.brost@...el.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241017111410.2553784-2-badal.nilawar@intel.com
Signed-off-by: Sasha Levin <sashal@...nel.org>
---
 drivers/gpu/drm/xe/xe_guc_ct.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
index 9c505d3517cd1..cd6a5f09d631e 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.c
+++ b/drivers/gpu/drm/xe/xe_guc_ct.c
@@ -906,6 +906,24 @@ static int guc_ct_send_recv(struct xe_guc_ct *ct, const u32 *action, u32 len,
 		}
 	}
 
+	/*
+	 * Occasionally it is seen that the G2H worker starts running after a delay of more than
+	 * a second even after being queued and activated by the Linux workqueue subsystem. This
+	 * leads to G2H timeout error. The root cause of issue lies with scheduling latency of
+	 * Lunarlake Hybrid CPU. Issue dissappears if we disable Lunarlake atom cores from BIOS
+	 * and this is beyond xe kmd.
+	 *
+	 * TODO: Drop this change once workqueue scheduling delay issue is fixed on LNL Hybrid CPU.
+	 */
+	if (!ret) {
+		flush_work(&ct->g2h_worker);
+		if (g2h_fence.done) {
+			xe_gt_warn(gt, "G2H fence %u, action %04x, done\n",
+				   g2h_fence.seqno, action[0]);
+			ret = 1;
+		}
+	}
+
 	/*
 	 * Ensure we serialize with completion side to prevent UAF with fence going out of scope on
 	 * the stack, since we have no clue if it will fire after the timeout before we can erase
-- 
2.43.0