Re: [PATCH 05/24] irq & spin_lock: Add counted interrupt disabling/enabling
Peter Zijlstra <[email protected]> Mon, 3 Aug 2026 12:21:55 +0200
| Newsgroups | org.kernel.vger.rust-for-linux,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Jul 31, 2026 at 01:30:06PM -0700, Boqun Feng wrote:
> +static inline void local_interrupt_disable(void)
> +{
> + unsigned long flags;
> + int new_count;
> +
> + WARN_ON_ONCE(in_nmi());
> +
> + new_count = hardirq_disable_enter();
> +
> + /* Interrupts can happen here, but it's OK, see __irq_exit_rcu(). */
> +
> + if ((new_count & HARDIRQ_DISABLE_MASK) == HARDIRQ_DISABLE_OFFSET) {
> + local_irq_save(flags);
> + raw_cpu_write(local_interrupt_disable_state.flags, flags);
> + }
> +}
> +
> +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 CONFIG_PREEMPTION
> + if (should_resched(0))
> + __preempt_schedule();
I'm confused by this one. This should not be needed. If there was a
preemption while IRQs were disabled, there should be a pending
IPI.
Notably local_irq_restore() also doesn't do this, since otherwise you
would not have needed to add this here, since you already call that.
> +#endif
> + }
> +}