Re: [PATCH] locking: Revert switching guards to _irq_{disable,enable}()

[Boqun Feng <boqun@kernel.org>]

On Fri, Aug 28, 2026 at 09:22:05AM +0100, David Laight wrote:
> On Thu, 27 Aug 2026 14:33:05 -0700
> Boqun Feng <boqun@kernel.org> wrote:
> 
> ....
> > Yes, if we go to the level to unify all irq disabling with counter
> > tracking then I think using arch_local_irq_disable() is possible and
> > makes a lot of senses.
> 
> Where are you thinking of keeping the counter?
> On non-x86 accessing it may be expensive.
> The best bet is probably in 'current'.
> 

The counter remains in preempt_count() as we already did for
local_interrupt_disable()?

> Doesn't that make this valid?
> 	int c = current->irq_disable_count;
> 	if (c) {
> 		current->irq_disable_count = c + 1;
> 		return c;
> 	}
> 	disable_irq(); // asm("cli")
> 	interrupt_disable_barrier(); // ISTR arm needs this
> 	current->irq_disable_count = 1;
> 	return 0;
> }
> 
> The task can be preempted in the middle - but that doesn't matter.
> 
> If spin_lock_irqsave() returns current->irq_disable_count then
> any existing code that does lock chaining works unaltered.
> 

yes, but someone could be creative and do:

	spin_lock_irqsave(l1, flag1);
	spin_lock_irqsave(l2, flag2);
	spin_unlock(l2);
	spin_unlock_irqrestore(l1, flag1);

basically, perfectly nesting and paired critical sections always work,
it's the unknown oddballs that we need to worry about.

Regards,
Boqun

> David
> 
> > 
> > Regards,
> > Boqun
> > 
> > > Thanks,
> > > 
> > >         tglx
> > >   
> > 
>