From nobody Sat Feb 7 21:08:13 2026 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) (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 DB649313294 for ; Fri, 14 Nov 2025 11:35:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763120125; cv=none; b=Kklwd4Oxe6ivfkhnidDq2ncicZDZSL8dfhblcAqDpCT6yVOr+osR+E93uuVmYHLT9yD4c/0XPleGPFUiz+k2VKbKKmrS+j1xLnzNqrQ9e4bD7r6m2+WYbTZlirpZuU4dafWZNAHYgI+ZRiRVqsAgTSxalZ/+QIt650GsfE4lrPI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763120125; c=relaxed/simple; bh=IgkoftSzpcr2o74s8YSHvlAzVsPvwdATJ93H5LnGwbI=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=XC1OrGC9HFTwydpXeZXoIyiAE9DSoEBh0G8slavezyfX3Kua6bv2R9Y6xGokjRnUGLj7lY/V8m5hu15ozmZs78sgKH1hlgJ75usl3NK9fSHefhaohUMTI7ghu3uKK9q+of4BKi16kjKWad/hT4HnPjJlT+3LmfQYItvKaYgTrCg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=lBx895di; arc=none smtp.client-ip=91.218.175.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="lBx895di" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1763120120; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=B+AoqtfsJG874YCsDG8SH6VgJOs7CzqrNzR7ODOmhCY=; b=lBx895dinudniqI9+Tu9XvjnIcgOxWucCkvnwC80rdYIn904YEtJeU5gHKCSO5PyCPNbm5 Nw2ByTb8kE9K7LD+jnaUitmsjgeNGE999hadDhtLuH0td4gXDUrW91AMqG15aJGxXk9fcD 2C/XfDa/X7faQzDxatrH0/h8dNYeTZY= From: Enlin Mu To: anna-maria@linutronix.de, frederic@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, enlin.mu@unisoc.com, enlin.mu@linux.dev Subject: [PATCH] hrtimer: Check running timer state Date: Fri, 14 Nov 2025 19:35:08 +0800 Message-Id: <20251114113508.3709-1-enlin.mu@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" When the running timer is not NULL, print debugging information. The test code is roughly as follows: static struct hrtimer serial_timer; enum hrtimer_restart serial_timer_handler(struct hrtimer * timer) { local_irq_disable(); ...... do_someting(); copy_data_with_dma(); ...... hrtimer_forward_now(*serial_timer, ns_to_ktime(1000*2000)); local_irq_enable(); return HRTIMER_RESTART; } static int serial_start(struct uart_port *port) { ...... ...... hrtime_init(&serial_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); ktime =3D no_to_ktime(1000*2000); serial_timer.function =3D serial_timer_handler; hrtimer_start(&serial_timer, ktime, HRTIMER_MODE_REL); ...... return 0; } static void serial_shutdown(struct uart_port *port) { ...... hrtimer_cancle(&serial_timer); ...... serial_release_dma(port); ...... } Kernel panic - not syning: Asynchronous SError Interrupt CPU: 6 PID: 7082 Comm: binder:542_1 Call trace: dump_backtrace+0xec/0x138 show_stack+0x18/0x28 show_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 panic+0x164/0x37c nmi_panic+0x8c/0x90 arm64_serror_panic+0x6c/0x94 do_serror+0xbc/0xc8 el1h_64_error_handler+0x34/0x4c el1h_64_error+0x68/0x6c readl+0x44/0x1dl dma_resume+0x34/0x68 serial_timer_handler+0x9c/0x38c __hrtimer_run_queues+0x1f0/0x400 hrtimer_interrupt+0xdc/0x39c arch_timer_hanler_phys+0x50/0x64 handler_percpu_devid_irq+0xb4/0x258 generic_handle_domain_irq+0x58/0x80 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 ....... The cpu6 canceled serial_timer and released dma,but the serial_timer still ran many times on CPU7 until a panic occurred. The reason for the panic is that serial_timer accessed the released dma,But the serial_timer had been canceled for some time now on cpu6. The cpu6 can successfully cancel the serial_timer because the running timer has changed and it is another timer(such as hrtimer_usb). When the serial_timer is enable to interrupt, the next hrtimer (such as hrtimer_usb) on cpu7 preempts the return of ther serial_timer, causing a change in the running timer. Signed-off-by: Enlin Mu Signed-off-by: Enlin Mu --- kernel/time/hrtimer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 88aa062b8a55..b7f00c39dd97 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -1743,6 +1743,7 @@ static void __run_hrtimer(struct hrtimer_cpu_base *cp= u_base, lockdep_assert_held(&cpu_base->lock); =20 debug_deactivate(timer); + WARN_ON_ONCE(base->running); base->running =3D timer; =20 /* --=20 2.39.5