linux-kernel - Re: [for-next][PATCH 2/2] atomic64: Use arch_spin_locks instead of raw_spin

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250122175701.GA34562@noisy.programming.kicks-ass.net>
Date: Wed, 22 Jan 2025 18:57:01 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Andrew Morton <akpm@...ux-foundation.org>, stable@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andreas Larsson <andreas@...sler.com>,
	Ludwig Rydberg <ludwig.rydberg@...sler.com>
Subject: Re: [for-next][PATCH 2/2] atomic64: Use arch_spin_locks instead of
 raw_spin_locks

On Wed, Jan 22, 2025 at 10:55:17AM -0500, Steven Rostedt wrote:

> > >  s64 generic_atomic64_read(const atomic64_t *v)
> > >  {
> > >  	unsigned long flags;
> > > -	raw_spinlock_t *lock = lock_addr(v);
> > > +	arch_spinlock_t *lock = lock_addr(v);
> > >  	s64 val;
> > >  
> > > -	raw_spin_lock_irqsave(lock, flags);
> > > +	local_irq_save(flags);
> > > +	arch_spin_lock(lock);  
> > 
> > Note that this is not an equivalent change. It's probably sufficient,
> > but at the very least the Changelog should call out what went missing
> > and how that is okay.
> 
> What exactly is the difference here that you are talking about? I know that
> raw_spin_lock_irqsave() has lots of different variants depending on the
> config options, but I'm not sure which you are talking about? Is it the fact
> that you can't do the different variants with this?

If I followed the maze right, then I get something like:

raw_spin_lock_irqsave(lock, flags)
  local_irq_save(flags);
  preempt_disable();
  arch_spin_lock(lock);
  mmiowb_spin_lock();


And here you leave out that preempt_disable() and mmiowb stuff. The
former is fine because local_irq_save() already makes things
non-preemptible and there are no irq-state games. The mmiowb thing is
fine because nothing inside this critical section cares about mmio.