From: Frederic Weisbecker <frederic@kernel.org>
To: Thomas Gleixner <tglx@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Calvin Owens <calvin@wbinvd.org>,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
John Stultz <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,
linux-pm@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>,
Florian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org
Subject: Re: [patch V2 01/11] hrtimer: Provide hrtimer_start_range_ns_user()
Date: Wed, 8 Apr 2026 18:53:16 +0200 [thread overview]
Message-ID: <adaH_AVmNLlRd3ep@localhost.localdomain> (raw)
In-Reply-To: <20260408114951.995031895@kernel.org>
Le Wed, Apr 08, 2026 at 01:53:46PM +0200, Thomas Gleixner a écrit :
> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked
> up in user space. He provided a reproducer, which set's up a timerfd based
> timer and then rearms it in a loop with an absolute expiry time of 1ns.
>
> As the expiry time is in the past, the timer ends up as the first expiring
> timer in the per CPU hrtimer base and the clockevent device is programmed
> with the minimum delta value. If the machine is fast enough, this ends up
> in a endless loop of programming the delta value to the minimum value
> defined by the clock event device, before the timer interrupt can fire,
> which starves the interrupt and consequently triggers the lockup detector
> because the hrtimer callback of the lockup mechanism is never invoked.
>
> The clockevents code already has a last resort mechanism to prevent that,
> but it's sensible to catch such issues before trying to reprogram the clock
> event device.
>
> Provide a variant of hrtimer_start_range_ns(), which sanity checks the
> timer after queueing it. It does not so before because the timer might be
> armed and therefore needs to be dequeued. also we optimize for the latest
> possible point to check, so that the clock event prevention is avoided as
> much as possible.
>
> If the timer is already expired _before_ the clock event is reprogrammed,
> remove the timer from the queue and signal to the caller that the operation
> failed by returning false.
>
> That allows the caller to take immediate action without going through the
> loops and hoops of the hrtimer interrupt.
>
> The queueing code can't invoke the timer callback as the caller might hold
> a lock which is taken in the callback.
>
> Add a tracepoint which allows to analyze the expired at start situation.
>
> Reported-by: Calvin Owens <calvin@wbinvd.org>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
> Cc: Frederic Weisbecker <frederic@kernel.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
--
Frederic Weisbecker
SUSE Labs
next prev parent reply other threads:[~2026-04-08 16:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 11:53 [patch V2 00/11] hrtimers: Prevent hrtimer interrupt starvation Thomas Gleixner
2026-04-08 11:53 ` [patch V2 01/11] hrtimer: Provide hrtimer_start_range_ns_user() Thomas Gleixner
2026-04-08 16:53 ` Frederic Weisbecker [this message]
2026-04-08 11:53 ` [patch V2 02/11] hrtimer: Use hrtimer_start_expires_user() for hrtimer sleepers Thomas Gleixner
2026-04-08 11:53 ` [patch V2 03/11] posix-timers: Expand timer_[re]arm() callbacks with a boolean return value Thomas Gleixner
2026-04-08 11:54 ` [patch V2 04/11] posix-timers: Handle the timer_[re]arm() " Thomas Gleixner
2026-04-08 11:54 ` [patch V2 05/11] posix-timers: Switch to hrtimer_start_expires_user() Thomas Gleixner
2026-04-08 11:54 ` [patch V2 06/11] alarmtimer: Provide alarm_start_timer() Thomas Gleixner
2026-04-08 11:54 ` [patch V2 07/11] alarmtimer: Convert posix timer functions to alarm_start_timer() Thomas Gleixner
2026-04-08 11:54 ` [patch V2 08/11] fs/timerfd: Use the new alarm/hrtimer functions Thomas Gleixner
2026-04-08 11:54 ` [patch V2 09/11] power: supply: charger-manager: Switch to alarm_start_timer() Thomas Gleixner
2026-04-08 11:54 ` [patch V2 10/11] netfilter: xt_IDLETIMER: " Thomas Gleixner
2026-04-08 11:54 ` [patch V2 11/11] alarmtimer: Remove unused interfaces Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=adaH_AVmNLlRd3ep@localhost.localdomain \
--to=frederic@kernel.org \
--cc=anna-maria@linutronix.de \
--cc=brauner@kernel.org \
--cc=calvin@wbinvd.org \
--cc=coreteam@netfilter.org \
--cc=fw@strlen.de \
--cc=jack@suse.cz \
--cc=jstultz@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=peterz@infradead.org \
--cc=phil@nwl.cc \
--cc=sboyd@kernel.org \
--cc=sre@kernel.org \
--cc=tglx@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox