Re: [RFC RESEND v10 03/14] irq & spin_lock: Add counted interrupt disabling/enabling
From: Boqun Feng
Date: Tue Jun 17 2025 - 10:39:28 EST
On Tue, Jun 17, 2025 at 10:11:20AM -0400, Steven Rostedt wrote:
> On Tue, 27 May 2025 18:21:44 -0400
> Lyude Paul <lyude@xxxxxxxxxx> wrote:
>
> > +static inline void local_interrupt_enable(void)
> > +{
> > + int new_count;
> > +
> > + new_count = hardirq_disable_exit();
> > +
> > + if ((new_count & HARDIRQ_DISABLE_MASK) == 0) {
> > + unsigned long flags;
> > +
> > + flags = raw_cpu_read(local_interrupt_disable_state.flags);
> > + local_irq_restore(flags);
> > + /*
> > + * TODO: re-read preempt count can be avoided, but it needs
> > + * should_resched() taking another parameter as the current
> > + * preempt count
> > + */
> > +#ifdef PREEMPTION
> > + if (should_resched(0))
> > + __preempt_schedule();
> > +#endif
> > + }
> > +}
>
> I'm confused to why the should_resched() is needed? We are handling
> interrupts right? The hardirq_disable_exit() will set preempt_count to zero
> before we enable interrupts. When the local_irq_restore() enables interrupts
> again, if there's an interrupt pending it will trigger then. If the
> interrupt sets NEED_RESCHED, when it returns from the interrupt handler, it
> will see preempt_count as zero, right?
>
Because the new local_interrupt_{disable, enable}() participate the
preempt count game as well, for example, __raw_spin_lock_irq_disable()
doesn't call an additional preempt_disable() and
__raw_spin_unlock_irq_enable() doesn't call preempt_enable(). And the
following can happen:
spin_lock(a);
// preemption is disabled.
<interrupted and set need_resched>
spin_lock_irq_disable(b);
spin_unlock(a);
spin_unlock_irq_enable(b):
local_interrupt_enable():
// need to check should_resched, otherwise preemption won't
// happen.
Regards,
Boqun
> If it does, then it will call schedule before it gets back to this code.
>
> -- Steve