Re: [RFC PATCH] entry: Account the deferred hrtimer rearm as hardirq context for lockdep

[Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>]

On Mon, Oct 12, 2026 at 05:21:20PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2026 at 01:46:49AM +0500, Mikhail Gavrilov wrote:
> > Not touched, and a question for you: the rearm in hrtick_schedule_exit()
> > also stacks chains on the preempted task's locks, under the runqueue lock.
> > Chains with hrtimer_bases.lock under the runqueue lock, this rearm among
> > them, were 4.9% of the pool in the boot above. Should it get the same
> > treatment?
>
> I'm thinking those would be there before the patch too. We've always
> done hrtimer_start() from there. You might not have seen it because
> hrtick was default disabled for most.

Right, hrtick_start() has always put hrtimer_bases.lock under the
runqueue lock, and 9213aa4784cf ("sched: Default enable HRTICK when
deferred rearming is enabled") is what made it common. I'll leave that
one alone.

> The first question I had was about __exit_to_usermode_prepare(), that
> also does hrtimer_rearm, but doesn't get wrapped. I'm thinking that's
> not a problem because at that point the lock stack is empty and all
> that. But perhaps a comment?

Yes, no locks can be held there. And since the chain key only covers
the locks taken since the last change of irq context, a rearm on an
empty lock stack lands in the same chains as the rearm in hardirq
context. In the 46.6 hour boot, the 16 chains starting with
hrtimer_bases.lock were all created in hardirq context, and no process
or softirq context chain starts with it.

For v2 I'd add to the comment above the helper:

 * The rearm on return to user mode needs no such annotation: no locks
 * are held there, so it uses the same lock chains as the rearm in
 * hardirq context.

> That said; I wonder if we want more of irqentry_exit_to_kernel_mode()
> wrapped like this. The schedule_preempt_irq() thing will now also stack
> rq->lock and the like on top of 'random' kernel stacks, rather than
> keeping it in 'empty' hardirq contexts.
>
> Or am I making a mess of things?

Apart from the rearm, the preemption is the only thing in there that
takes locks, and I don't see a way to run it in lockdep's hardirq
context: preempt_schedule_irq() enables interrupts before calling
__schedule(), which trips the lockdep_hardirq_context() check in
lockdep_hardirqs_on_prepare(), and hardirq_context is per CPU, so it
would stay set for whatever task __schedule() switches to.

Nor is the shape specific to the interrupt return: schedule() under a
held sleeping lock stacks rq->lock on that lock the same way. In the
46.6 hour boot, chains with rq->__lock on top of other held locks were
18.1% of the pool, and lockdep_chains does not tell which of them came
from preemption.

-- 
Thanks,
Mikhail