[PATCH v2] tty: hvc: dcc: Detect JTAG connection only on CPU core 0

[PATCH v2] tty: hvc: dcc: Detect JTAG connection only on CPU core 0

[shatyuka]

From: Jiannan Du <shatyuka@qq.com>

On SMP, migration can occur inside hvc_dcc_check() during
device_initcall, so the CPU writing the probe character and the CPU
reading the TXfull status may not be the same, which can hang the
system.

Commit 4419da5d5d4b1788568b ("tty: hvc: dcc: Bind driver to CPU core0
for reads and writes") cached the DCC availability detected on core 0
during console_initcall. However, this is not sufficient: if DCC is
not detected as available and another CPU later calls
hvc_dcc_check(), the check is not actually performed on core 0.

Multiple checks are unnecessary: nobody is going to plug/unplug JTAG
during kernel boot and expect it to work. Cache the return value of
hvc_dcc_check() from device_initcall and reuse the cached value during
console_initcall. This avoids complex SMP-related code and ensures the
result is always from core 0.

Signed-off-by: Jiannan Du <shatyuka@qq.com>
---
Changes in v2:
 - Use my real name in Signed-off-by
---
 drivers/tty/hvc/hvc_dcc.c | 30 ++++++++----------------------
 1 file changed, 8 insertions(+), 22 deletions(-)

diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c
index dfc5c9c38f0..fc8dcbce9b5 100644
--- a/drivers/tty/hvc/hvc_dcc.c
+++ b/drivers/tty/hvc/hvc_dcc.c
@@ -29,6 +29,9 @@ static DEFINE_SPINLOCK(dcc_lock);
 static DEFINE_KFIFO(inbuf, u8, DCC_INBUF_SIZE);
 static DEFINE_KFIFO(outbuf, u8, DCC_OUTBUF_SIZE);
 
+/* Cached result of hvc_dcc_check() */
+static bool dcc_core0_available;
+
 static void dcc_uart_console_putchar(struct uart_port *port, u8 ch)
 {
 	while (__dcc_getstatus() & DCC_STATUS_TX)
@@ -90,36 +93,18 @@ static ssize_t hvc_dcc_get_chars(uint32_t vt, u8 *buf, size_t count)
 }
 
 /*
- * Check if the DCC is enabled. If CONFIG_HVC_DCC_SERIALIZE_SMP is enabled,
- * then we assume then this function will be called first on core0. That way,
- * dcc_core0_available will be true only if it's available on core0.
+ * Check if the DCC is enabled. This function will be called once on core 0.
  */
 static bool hvc_dcc_check(void)
 {
 	unsigned long time = jiffies + (HZ / 10);
-	static bool dcc_core0_available;
-
-	/*
-	 * If we're not on core 0, but we previously confirmed that DCC is
-	 * active, then just return true.
-	 */
-	int cpu = get_cpu();
-
-	if (IS_ENABLED(CONFIG_HVC_DCC_SERIALIZE_SMP) && cpu && dcc_core0_available) {
-		put_cpu();
-		return true;
-	}
-
-	put_cpu();
 
 	/* Write a test character to check if it is handled */
 	__dcc_putchar('\n');
 
 	while (time_is_after_jiffies(time)) {
-		if (!(__dcc_getstatus() & DCC_STATUS_TX)) {
-			dcc_core0_available = true;
+		if (!(__dcc_getstatus() & DCC_STATUS_TX))
 			return true;
-		}
 	}
 
 	return false;
@@ -265,7 +250,8 @@ static int __init hvc_dcc_console_init(void)
 {
 	int ret;
 
-	if (!hvc_dcc_check())
+	dcc_core0_available = hvc_dcc_check();
+	if (!dcc_core0_available)
 		return -ENODEV;
 
 	/* Returns -1 if error */
@@ -279,7 +265,7 @@ static int __init hvc_dcc_init(void)
 {
 	struct hvc_struct *p;
 
-	if (!hvc_dcc_check())
+	if (!dcc_core0_available)
 		return -ENODEV;
 
 	if (IS_ENABLED(CONFIG_HVC_DCC_SERIALIZE_SMP)) {
-- 
2.36.1

Re: [PATCH v2] tty: hvc: dcc: Detect JTAG connection only on CPU core 0

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] tty: hvc_dcc: commit message contradicts caching sequence implementation
--

commit 5ac910cf6c31d8b744bac3d1aa1c60fcaa2dafb2
Author: Jiannan Du <shatyuka@qq.com>

tty: hvc: dcc: Detect JTAG connection only on CPU core 0

This commit attempts to fix a potential SMP issue where the JTAG connection
check could occur on a different CPU than core 0. It simplifies the check by
caching the result from one initcall and reusing it in a later initcall.

> Multiple checks are unnecessary: nobody is going to plug/unplug JTAG
> during kernel boot and expect it to work. Cache the return value of
> hvc_dcc_check() from device_initcall and reuse the cached value during
> console_initcall. This avoids complex SMP-related code and ensures the
> result is always from core 0.

[Severity: Medium]
Does the commit message have the sequence reversed?

The commit message explicitly claims to cache the return value from
device_initcall and reuse it during console_initcall. However, the
implementation does the exact opposite.

In drivers/tty/hvc/hvc_dcc.c, hvc_dcc_console_init() (a console_initcall) calls
hvc_dcc_check() and stores the result in dcc_core0_available:

	dcc_core0_available = hvc_dcc_check();
	if (!dcc_core0_available)
		return -ENODEV;

Then, hvc_dcc_init() (a device_initcall, which runs later) reuses this cached
value without calling hvc_dcc_check() again:

	if (!dcc_core0_available)
		return -ENODEV;

The code appears correct since console_initcall runs before device_initcall,
but the commit message misrepresents the boot sequence ordering, which makes
verifying the SMP safety claims confusing.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_A0A4CA13FA8B0F7ABF62EE438764D032F205@qq.com?part=1