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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250122101457.GG7145@noisy.programming.kicks-ass.net>
Date: Wed, 22 Jan 2025 11:14:57 +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 Tue, Jan 21, 2025 at 03:19:44PM -0500, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@...dmis.org>
> 
> raw_spin_locks can be traced by lockdep or tracing itself. Atomic64
> operations can be used in the tracing infrastructure. When an architecture
> does not have true atomic64 operations it can use the generic version that
> disables interrupts and uses spin_locks.
> 
> The tracing ring buffer code uses atomic64 operations for the time
> keeping. But because some architectures use the default operations, the
> locking inside the atomic operations can cause an infinite recursion.
> 
> As atomic64 is an architecture specific operation, it should not 

used in generic code :-)

> be using
> raw_spin_locks() but instead arch_spin_locks as that is the purpose of
> arch_spin_locks. To be used in architecture specific implementations of
> generic infrastructure like atomic64 operations.

Urgh.. this is horrible. This is why you shouldn't be using atomic64 in
generic code much :/

Why not just drop support for those cummy archs? Or drop whatever trace
feature depends on this.


>  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.