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.