Re: [PATCH 05/24] irq & spin_lock: Add counted interrupt disabling/enabling

[Peter Zijlstra]

On Mon, Aug 03, 2026 at 04:33:15PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 03, 2026 at 04:21:06PM +0200, Peter Zijlstra wrote:
> 
> > No; for one, you cannot elide the preempt_disable/enable() from this
> > thing.
> > 
> > It has always been valid to do:
> > 
> > 	raw_spin_lock_irq(lock);
> > 	...
> > 	raw_spin_unlock(lock);
> > 	...
> > 	local_irq_enable();
> > 
> > And since raw_spin_unlock() does have the preemption thing,
> > raw_spin_lock_irq() must too. And the very same argument is still valid
> > if you now write:
> > 
> > 	raw_spin_lock_irq_disable(lock);
> > 	...
> > 	raw_spin_unlock(lock);
> > 	...
> > 	local_interrupt_enable();
> > 
> > Secondly, nothing should 'set' NEED_RESCHED without also immediately
> > causing a preemption.
> 
> Notably, scheduler_ipi() is the one that folds TIF_NEED_RESCHED into
> PREEMPT_NEED_RESCHED for remote reschedules.

(and note that this is exactly the from hardirq context on current usage
as per the below...)

> Other than that, set_preempt_need_resched() must always be used from
> hardirq context or inside the schedule() loop on current. When used from
> hardirq context, the interrupt-return path will handle the reschedule,
> when used inside the schedule() loop, the loop will.
> 
> No other fiddling of NEED_RESCHED should occur.