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

Peter Zijlstra <[email protected]> Mon, 3 Aug 2026 16:33:15 +0200
Newsgroups org.kernel.vger.rust-for-linux,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
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.

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.