linux-kernel - [PATCH] hrtimer: Check running timer state

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>] [day] [month] [year] [list]

Message-Id: <20251114113508.3709-1-enlin.mu@linux.dev>
Date: Fri, 14 Nov 2025 19:35:08 +0800
From: Enlin Mu <enlin.mu@...ux.dev>
To: anna-maria@...utronix.de,
	frederic@...nel.org,
	tglx@...utronix.de,
	linux-kernel@...r.kernel.org,
	enlin.mu@...soc.com,
	enlin.mu@...ux.dev
Subject: [PATCH] hrtimer: Check running timer state

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 = no_to_ktime(1000*2000);
	serial_timer.function = 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 <enlin.mu@...ux.dev>
Signed-off-by: Enlin Mu <enlin.mu@...soc.com>
---
 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 *cpu_base,
 	lockdep_assert_held(&cpu_base->lock);
 
 	debug_deactivate(timer);
+	WARN_ON_ONCE(base->running);
 	base->running = timer;
 
 	/*
-- 
2.39.5