Re: [PATCH] timers: Stop hrtimer queue traversal after seq_file overflow

[Frederic Weisbecker]

Le Tue, Nov 03, 2026 at 12:34:39PM +0200, Avi Weiss a écrit :
> When /proc/timer_list overflows its seq_file buffer, seq_file retries
> formatting with a larger buffer. print_active_timers() nevertheless
> continues scanning the remaining hrtimers, restarting its quadratic
> traversal even though the overflowing attempt will be discarded.
> 
> Stop traversing at next_one when the seq_file has overflowed. Preserve
> the SysRq console path, which passes a NULL seq_file pointer.
> 
> In a (virtual) two-CPU KVM guest with 2,048 timerfds pinned to one CPU,
> median reader CPU time for a complete /proc/timer_list read fell from
> 51.1 ms to 14.6 ms. Repeated tests showed no material slowdown for
> non-overflowing reads (13.7us before versus 13.8 after). Short reads,
> seek-to-start, and SysRq-Q tests also look fine.
> 
> Fixes: 289f480af87e ("[PATCH] Add debugging feature /proc/timer_list")
> Signed-off-by: Avi Weiss <thnkslprpt@xxxxxxxxx>
> ---
>  kernel/time/timer_list.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
> index 0406bf4488e9..84275b6cd2c9 100644
> --- a/kernel/time/timer_list.c
> +++ b/kernel/time/timer_list.c
> @@ -64,6 +64,8 @@ static void print_active_timers(struct seq_file *m, struct hrtimer_clock_base *b
>  	unsigned long flags;
>  
>  next_one:
> +	if (m && seq_has_overflowed(m))
> +		return;

But it's harmless, right? I mean the bad outcome is just to spend useless cycles
seeking and storing?

Still probably makes sense though.

>  	i = 0;
>  
>  	touch_nmi_watchdog();
> -- 
> 2.43.0
> 

-- 
Frederic Weisbecker
SUSE Labs