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