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

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Oct 15, 2025 at 01:54:05PM -0700, Bart Van Assche wrote:

> > This also makes the wrapper of interrupt-disabling locks on Rust easier
> > to design.
> 
> Is a new counter really required to fix the issues that exist in the
> above examples? Has it been considered to remove the spin_lock_irqsave()
> and spin_lock_irqrestore() definitions, to introduce a macro that saves
> the interrupt state in a local variable and restores the interrupt state
> from the same local variable? With this new macro, the first two examples
> above would be changed into the following (this code has not been tested
> in any way):

So the thing is that actually frobbing the hardware interrupt state is
relatively expensive. On x86 things like PUSHF/POPF/CLI/STI are
definitely on the 'nice to avoid' side of things.

Various people have written patches to avoid them on x86, and while none
of them have made it, they did show benefit (notably PowerPC already
does something tricky because for them it is *really* expensive).

So in that regard, keeping this counter allows us to strictly reduce the
places where we have to touch IF. The interface is nicer too, so a win
all-round.

My main objection to all this has been that they add to the interface
instead of replace the interface. Ideally this would implement
spin_lock_irq() and spin_lock_irqsave() in terms of the new
spin_lock_irq_disable() and then we go do tree wide cleanups over a few
cycles.

The problem is that that requires non-trivial per architecture work and
they've so far tried to avoid this...