Re: [for-next][PATCH 2/2] atomic64: Use arch_spin_locks instead of raw_spin_locks

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Jan 21, 2025 at 03:19:44PM -0500, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.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.