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.