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

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Oct 13, 2026 at 11:04:48AM +0500, Mikhail Gavrilov wrote:
> On Mon, Oct 12, 2026 at 05:21:20PM +0200, Peter Zijlstra wrote:

> > 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.

Right; that won't do.

> 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.

That's roughly 2 out of 11. Not sure that's worth it. If I get another
crazy idea I'll let you know ;-)