linux-kernel - Re: [PATCH] spin_lock_irqsave() in autofs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250821130342.15ebaa26@pumpkin>
Date: Thu, 21 Aug 2025 13:03:42 +0100
From: David Laight <david.laight.linux@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Al Viro <viro@...iv.linux.org.uk>, Ian Kent <raven@...maw.net>,
 autofs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] spin_lock_irqsave() in autofs_write() is bogus

On Sun, 17 Aug 2025 09:50:25 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Sun, 17 Aug 2025 at 09:36, Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> >         That function should never be (and never is) called with irqs
> > disabled - we have an explicit mutex_lock() in there, if nothing else.
> > Which makes spin_lock_irqsave() use in there pointless - we do need to
> > disable irqs for ->siglock, but that should be spin_lock_irq().  
> 
> I think we basically did the irqsave/restore version as the default
> when not wanting to think about the context.
> 
> Your patch looks fine, but I doubt it's measurable outside of "it
> makes the code a few bytes smaller".

There is a separate problem with all non-irqsave spin locks.
The lock hold time for spin locks is expected to be short,
perhaps only a few instruction.
(If the hold time is long it shouldn't be a spin lock...)

So disabling interrupts won't have a significant effect on interrupt
latency.

OTOH if an interrupt happens while the spin lock is help the lock
hold time is extended until the interrupt completes.
Get caught by an ethernet rx interrupt and it can be a very long
time (easily several milliseconds) before the hardware interrupt
and soft-int code returns.
During that time any other code attempting to acquire the lock
will spin.

So you may want to disable interrupts on all spin locks.
The downside is that the disable/enable isn't cheap on a lot
of systems.
I'm sure something could be done with the 'pre-empt disable'
counter to conditionally enable/disable interrupts.

There have also been systems that don't actually disable interrupts,
they just set a flag.
When an interrupt happens 'magic' is done so that the ISR can return
and the interrupt processed when (eg) the spin lock is released.

	David