[BUG] spinlock recursion when enabling function tracer on 32-bit

[BUG] spinlock recursion when enabling function tracer on 32-bit

[Ludwig Rydberg]

Dear maintainers,

When I try to enable the function tracer using Linux 6.13.0-rc3 on some
32-bit systems (tested on qemu-riscv32 and LEON4-sparc32) a BUG message
about spinlock recursion is printed and the system becomes unresponsive.

Steps to reproduce the issue:
# mount -t tracefs nodev /sys/kernel/tracing
# echo function > /sys/kernel/tracing/current_tracer
[   16.204882] BUG: spinlock recursion on CPU#0, sh/117
[   16.205758] lock: atomic64_lock+0x0/0x400, .magic: dead4ead, .owner:
sh/117,
.owner_cpu: 0
[   16.206564] CPU: 0 UID: 0 PID: 117 Comm: sh Not tainted 6.13.0-rc3 #7
[   16.206777] Hardware name: riscv-virtio,qemu (DT)
[   16.206966] Call Trace:
[   16.207245] dump_backtrace (arch/riscv/kernel/stacktrace.c:131)
[   16.207392] show_stack (arch/riscv/kernel/stacktrace.c:137)
[   16.207497] dump_stack_lvl (lib/dump_stack.c:122)
[   16.207623] dump_stack (lib/dump_stack.c:130)
[   16.207745] spin_dump (kernel/locking/spinlock_debug.c:71)
[   16.207859] do_raw_spin_lock (kernel/locking/spinlock_debug.c:78
kernel/locking/spinlock_debug.c:87 kernel/locking/spinlock_debug.c:115)
[   16.207999] _raw_spin_lock_irqsave (kernel/locking/spinlock.c:163)
[   16.208139] generic_atomic64_read (lib/atomic64.c:51)
[   16.208284] __rb_reserve_next.constprop.0
(kernel/trace/ring_buffer.c:608 kernel/trace/ring_buffer.c:4262)
[   16.208437] ring_buffer_lock_reserve (kernel/trace/ring_buffer.c:4454
(discriminator 2) kernel/trace/ring_buffer.c:4511 (discriminator 2))
[   16.208585] trace_function (kernel/trace/trace.c:1021
kernel/trace/trace.c:2906)
[   16.208715] function_trace_call (kernel/trace/trace_functions.c:222)
[   16.208854] ftrace_call (arch/riscv/kernel/mcount-dyn.S:178)
[   16.208981] __rb_reserve_next.constprop.0
(kernel/trace/ring_buffer.c:608 kernel/trace/ring_buffer.c:4262)
[   16.209133] ring_buffer_lock_reserve (kernel/trace/ring_buffer.c:4454
(discriminator 2) kernel/trace/ring_buffer.c:4511 (discriminator 2))
[   16.209282] trace_function (kernel/trace/trace.c:1021
kernel/trace/trace.c:2906)
[   16.209411] function_trace_call (kernel/trace/trace_functions.c:222)
[   16.209546] ftrace_call (arch/riscv/kernel/mcount-dyn.S:178)
[   16.209666] tracing_set_trace_write (kernel/trace/trace.c:6377)
[   16.209802] vfs_write (fs/read_write.c:677 fs/read_write.c:659)
[   16.209920] ksys_write (fs/read_write.c:731)
[   16.210040] __se_sys_write (fs/read_write.c:739)
[   16.210179] __riscv_sys_write (fs/read_write.c:739)
[   16.210312] do_trap_ecall_u (./arch/riscv/include/asm/syscall.h:90
(discriminator 1) arch/riscv/kernel/traps.c:331 (discriminator 1))
[   16.210441] handle_exception (arch/riscv/kernel/entry.S:198)

The issue seems to have been introduced by the following commit:
c84897c0ff59 ("ring-buffer: Remove 32bit timestamp logic")

I did a quick test to revert the patch and then its possible to enable
the function tracer on Linux 6.13-rc3.

An observation I made is that CONFIG_GENERIC_ATOMIC64 is enabled on the
systems I have tested on and I can see that there is a call to
generic_atomic64_read (i.e local64_read from the ring buffer) in the
call trace leading up to the warning. Not sure if its the root-cause but
it could perhaps be related.

Is this a known problem? I tried to find any previous reports but could
not find any. Please let me know if you need more details.

Best regards,
// Ludwig

--

Test environment:
ARCH=riscv32
Buildroot 2024.11
QEMU 6.2.0
Buildroot config: qemu_riscv32_virt_defconfig
Linux tag: v6.13-rc3
Linux buildroot 6.13.0-rc3 #5 SMP Wed Dec 18 12:58:40 CET 2024 riscv32
GNU/Linux

Re: [BUG] spinlock recursion when enabling function tracer on 32-bit

[Steven Rostedt]

On Wed, 18 Dec 2024 15:57:02 +0100
Ludwig Rydberg <ludwig.rydberg@gaisler.com> wrote:

> Dear maintainers,
> 
> When I try to enable the function tracer using Linux 6.13.0-rc3 on some
> 32-bit systems (tested on qemu-riscv32 and LEON4-sparc32) a BUG message
> about spinlock recursion is printed and the system becomes unresponsive.
> 
> Steps to reproduce the issue:
> # mount -t tracefs nodev /sys/kernel/tracing
> # echo function > /sys/kernel/tracing/current_tracer
> [   16.204882] BUG: spinlock recursion on CPU#0, sh/117
> [   16.205758] lock: atomic64_lock+0x0/0x400, .magic: dead4ead, .owner:
> sh/117,
> .owner_cpu: 0
> [   16.206564] CPU: 0 UID: 0 PID: 117 Comm: sh Not tainted 6.13.0-rc3 #7
> [   16.206777] Hardware name: riscv-virtio,qemu (DT)
> [   16.206966] Call Trace:
> [   16.207245] dump_backtrace (arch/riscv/kernel/stacktrace.c:131)
> [   16.207392] show_stack (arch/riscv/kernel/stacktrace.c:137)
> [   16.207497] dump_stack_lvl (lib/dump_stack.c:122)
> [   16.207623] dump_stack (lib/dump_stack.c:130)
> [   16.207745] spin_dump (kernel/locking/spinlock_debug.c:71)
> [   16.207859] do_raw_spin_lock (kernel/locking/spinlock_debug.c:78
> kernel/locking/spinlock_debug.c:87 kernel/locking/spinlock_debug.c:115)

> [   16.207999] _raw_spin_lock_irqsave (kernel/locking/spinlock.c:163)
> [   16.208139] generic_atomic64_read (lib/atomic64.c:51)

Grumble. This is due to your architecture using the atomic64 code that
takes spin locks.

I'm not bringing back the logic that the commit you specified removed.

Hmm, we do have recursion protection, but it allows one loop to handle
transitions between normal and interrupt context. If we stop that
transition for archs that use the generic atomic64, I wonder if that would
fix things.

Can you try this patch?

-- Steve

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 7e257e855dd1..c402874a979b 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -3935,6 +3935,9 @@ trace_recursive_lock(struct ring_buffer_per_cpu *cpu_buffer)
 	bit = RB_CTX_NORMAL - bit;
 
 	if (unlikely(val & (1 << (bit + cpu_buffer->nest)))) {
+		/* Do not allow any recursion for archs using locks for atomic64 */
+		if (IS_ENABLED(CONFIG_GENERIC_ATOMIC64))
+			return true;
 		/*
 		 * It is possible that this was called by transitioning
 		 * between interrupt context, and preempt_count() has not

Re: [BUG] spinlock recursion when enabling function tracer on 32-bit

[Ludwig Rydberg]

On 2024-12-18 17:01, Steven Rostedt wrote:

> Hmm, we do have recursion protection, but it allows one loop to handle
> transitions between normal and interrupt context. If we stop that
> transition for archs that use the generic atomic64, I wonder if that would
> fix things.
> 
> Can you try this patch?

Thanks!

I applied the patch and did some testing and the initial issue I reported
seems to have been fixed but unfortunately I'm still able to trigger
a spinlock recursion.

The following sequence works fine with the patch applied:
# echo function > current_tracer
# echo 1 > tracing_on
# usleep 1
# echo 0 > tracing_on
# cat trace
# ...

But this triggers a spinlock recursion:
# echo 1 > tracing_on
# find /

[   61.276675] BUG: spinlock recursion on CPU#0, find/119
[   61.277571]  lock: 0xc1c076c0, .magic: dead4ead, .owner: find/119, .owner_cpu: 0
[   61.278365] CPU: 0 UID: 0 PID: 119 Comm: find Not tainted 6.13.0-rc3 #5
[   61.278724] Hardware name: riscv-virtio,qemu (DT)
[   61.278994] Call Trace:
[   61.279351] dump_backtrace (arch/riscv/kernel/stacktrace.c:131)
[   61.279848] show_stack (arch/riscv/kernel/stacktrace.c:137)
[   61.280022] dump_stack_lvl (lib/dump_stack.c:122)
[   61.280202] dump_stack (lib/dump_stack.c:130)
[   61.280372] spin_dump (kernel/locking/spinlock_debug.c:71)
[   61.280534] do_raw_spin_lock (kernel/locking/spinlock_debug.c:78 kernel/locking/spinlock_debug.c:87 kernel/locking/spinlock_debug.c:115)
[   61.280714] _raw_spin_lock_irqsave (kernel/locking/spinlock.c:163)
[   61.280905] generic_atomic64_read (lib/atomic64.c:51)
[   61.281091] __rb_reserve_next.constprop.0 (kernel/trace/ring_buffer.c:608 kernel/trace/ring_buffer.c:4265)
[   61.281299] ring_buffer_lock_reserve (kernel/trace/ring_buffer.c:4457 (discriminator 2) kernel/trace/ring_buffer.c:4514 (discriminator 2))
[   61.281496] trace_function (kernel/trace/trace.c:1021 kernel/trace/trace.c:2906)
[   61.281672] function_trace_call (kernel/trace/trace_functions.c:222)
[   61.281859] ftrace_call (arch/riscv/kernel/mcount-dyn.S:178)
[   61.282030] inode_query_iversion (fs/libfs.c:2050)
[   61.282217] ext4_readdir (fs/ext4/dir.c:597 fs/ext4/dir.c:143)
[   61.282393] iterate_dir (fs/readdir.c:109)
[   61.282562] __se_sys_getdents64 (fs/readdir.c:403 fs/readdir.c:389)
[   61.282758] __riscv_sys_getdents64 (fs/readdir.c:389)
[   61.282945] do_trap_ecall_u (./arch/riscv/include/asm/syscall.h:90 (discriminator 1) arch/riscv/kernel/traps.c:331 (discriminator 1))
[   61.283121] handle_exception (arch/riscv/kernel/entry.S:198)

// Ludwig

Re: [BUG] spinlock recursion when enabling function tracer on 32-bit

[Steven Rostedt]

On Wed, 18 Dec 2024 22:05:20 +0100
Ludwig Rydberg <ludwig.rydberg@gaisler.com> wrote:

> I applied the patch and did some testing and the initial issue I reported
> seems to have been fixed but unfortunately I'm still able to trigger
> a spinlock recursion.
> 
> The following sequence works fine with the patch applied:
> # echo function > current_tracer
> # echo 1 > tracing_on
> # usleep 1
> # echo 0 > tracing_on
> # cat trace
> # ...
> 
> But this triggers a spinlock recursion:
> # echo 1 > tracing_on
> # find /
> 
> [   61.276675] BUG: spinlock recursion on CPU#0, find/119
> [   61.277571]  lock: 0xc1c076c0, .magic: dead4ead, .owner: find/119, .owner_cpu: 0
> [   61.278365] CPU: 0 UID: 0 PID: 119 Comm: find Not tainted 6.13.0-rc3 #5
> [   61.278724] Hardware name: riscv-virtio,qemu (DT)
> [   61.278994] Call Trace:

OK, let's forget that then. Since these locks are really architecture
specific just to implement 64bit atomics on 32bit systems, they really
should be arch_spin_lock() and not raw_spin_lock(). raw_spin_lock() gets
traced (and there's a lot of debugging that can happen when they are
traced).

But arch_spin_lock() does not get traced, and is used in the tracing
and lockdep infrastructure. As these locks are never generic (archs that
have 64 bit atomics don't need them), lets switch them over to
arch_spin_lock().

Can you test this patch?

-- Steve

diff --git a/lib/atomic64.c b/lib/atomic64.c
index caf895789a1e..1a72bba36d24 100644
--- a/lib/atomic64.c
+++ b/lib/atomic64.c
@@ -25,15 +25,15 @@
  * Ensure each lock is in a separate cacheline.
  */
 static union {
-	raw_spinlock_t lock;
+	arch_spinlock_t lock;
 	char pad[L1_CACHE_BYTES];
 } atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp = {
 	[0 ... (NR_LOCKS - 1)] = {
-		.lock =  __RAW_SPIN_LOCK_UNLOCKED(atomic64_lock.lock),
+		.lock =  __ARCH_SPIN_LOCK_UNLOCKED,
 	},
 };
 
-static inline raw_spinlock_t *lock_addr(const atomic64_t *v)
+static inline arch_spinlock_t *lock_addr(const atomic64_t *v)
 {
 	unsigned long addr = (unsigned long) v;
 
@@ -45,12 +45,14 @@ static inline raw_spinlock_t *lock_addr(const atomic64_t *v)
 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);
 	val = v->counter;
-	raw_spin_unlock_irqrestore(lock, flags);
+	arch_spin_unlock(lock);
+	local_irq_restore(flags);
 	return val;
 }
 EXPORT_SYMBOL(generic_atomic64_read);
@@ -58,11 +60,13 @@ EXPORT_SYMBOL(generic_atomic64_read);
 void generic_atomic64_set(atomic64_t *v, s64 i)
 {
 	unsigned long flags;
-	raw_spinlock_t *lock = lock_addr(v);
+	arch_spinlock_t *lock = lock_addr(v);
 
-	raw_spin_lock_irqsave(lock, flags);
+	local_irq_save(flags);
+	arch_spin_lock(lock);
 	v->counter = i;
-	raw_spin_unlock_irqrestore(lock, flags);
+	arch_spin_unlock(lock);
+	local_irq_restore(flags);
 }
 EXPORT_SYMBOL(generic_atomic64_set);
 
@@ -70,11 +74,13 @@ EXPORT_SYMBOL(generic_atomic64_set);
 void generic_atomic64_##op(s64 a, atomic64_t *v)			\
 {									\
 	unsigned long flags;						\
-	raw_spinlock_t *lock = lock_addr(v);				\
+	arch_spinlock_t *lock = lock_addr(v);				\
 									\
-	raw_spin_lock_irqsave(lock, flags);				\
+	local_irq_save(flags);						\
+	arch_spin_lock(lock);						\
 	v->counter c_op a;						\
-	raw_spin_unlock_irqrestore(lock, flags);			\
+	arch_spin_unlock(lock);						\
+	local_irq_restore(flags);					\
 }									\
 EXPORT_SYMBOL(generic_atomic64_##op);
 
@@ -82,12 +88,14 @@ EXPORT_SYMBOL(generic_atomic64_##op);
 s64 generic_atomic64_##op##_return(s64 a, 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);						\
 	val = (v->counter c_op a);					\
-	raw_spin_unlock_irqrestore(lock, flags);			\
+	arch_spin_unlock(lock);						\
+	local_irq_restore(flags);					\
 	return val;							\
 }									\
 EXPORT_SYMBOL(generic_atomic64_##op##_return);
@@ -96,13 +104,15 @@ EXPORT_SYMBOL(generic_atomic64_##op##_return);
 s64 generic_atomic64_fetch_##op(s64 a, 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);						\
 	val = v->counter;						\
 	v->counter c_op a;						\
-	raw_spin_unlock_irqrestore(lock, flags);			\
+	arch_spin_unlock(lock);						\
+	local_irq_restore(flags);					\
 	return val;							\
 }									\
 EXPORT_SYMBOL(generic_atomic64_fetch_##op);
@@ -131,14 +141,16 @@ ATOMIC64_OPS(xor, ^=)
 s64 generic_atomic64_dec_if_positive(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);
 	val = v->counter - 1;
 	if (val >= 0)
 		v->counter = val;
-	raw_spin_unlock_irqrestore(lock, flags);
+	arch_spin_unlock(lock);
+	local_irq_restore(flags);
 	return val;
 }
 EXPORT_SYMBOL(generic_atomic64_dec_if_positive);
@@ -146,14 +158,16 @@ EXPORT_SYMBOL(generic_atomic64_dec_if_positive);
 s64 generic_atomic64_cmpxchg(atomic64_t *v, s64 o, s64 n)
 {
 	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);
 	val = v->counter;
 	if (val == o)
 		v->counter = n;
-	raw_spin_unlock_irqrestore(lock, flags);
+	arch_spin_unlock(lock);
+	local_irq_restore(flags);
 	return val;
 }
 EXPORT_SYMBOL(generic_atomic64_cmpxchg);
@@ -161,13 +175,15 @@ EXPORT_SYMBOL(generic_atomic64_cmpxchg);
 s64 generic_atomic64_xchg(atomic64_t *v, s64 new)
 {
 	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);
 	val = v->counter;
 	v->counter = new;
-	raw_spin_unlock_irqrestore(lock, flags);
+	arch_spin_unlock(lock);
+	local_irq_restore(flags);
 	return val;
 }
 EXPORT_SYMBOL(generic_atomic64_xchg);
@@ -175,14 +191,16 @@ EXPORT_SYMBOL(generic_atomic64_xchg);
 s64 generic_atomic64_fetch_add_unless(atomic64_t *v, s64 a, s64 u)
 {
 	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);
 	val = v->counter;
 	if (val != u)
 		v->counter += a;
-	raw_spin_unlock_irqrestore(lock, flags);
+	arch_spin_unlock(lock);
+	local_irq_restore(flags);
 
 	return val;
 }

Re: [BUG] spinlock recursion when enabling function tracer on 32-bit

[Ludwig Rydberg]

On 2024-12-18 22:35, Steven Rostedt wrote:

> 
> Can you test this patch?
> 

I have tested the patch on both riscv32 (qemu) & sparc32 (leon) and it seems
to be working fine.

But I can mention that I ran into a deadlock situation on sparc32.
I had to remove CC_FLAGS_FTRACE for the code that is responsible for
flushing TLBs (SMP). It uses an NMI to signal other CPUs which triggered
the deadlock if tracing was enabled on that path.

Best regards,
// Ludwig

 


      

Re: [BUG] spinlock recursion when enabling function tracer on 32-bit

[Steven Rostedt]

On Fri, 20 Dec 2024 14:55:27 +0100
Ludwig Rydberg <ludwig.rydberg@gaisler.com> wrote:

> On 2024-12-18 22:35, Steven Rostedt wrote:
> 
> > 
> > Can you test this patch?
> >   
> 
> I have tested the patch on both riscv32 (qemu) & sparc32 (leon) and it seems
> to be working fine.
> 
> But I can mention that I ran into a deadlock situation on sparc32.
> I had to remove CC_FLAGS_FTRACE for the code that is responsible for
> flushing TLBs (SMP). It uses an NMI to signal other CPUs which triggered
> the deadlock if tracing was enabled on that path.

Can you try this patch on top of the last one?

-- Steve

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 7e257e855dd1..a9fe54b79ce5 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -4398,8 +4398,13 @@ rb_reserve_next_event(struct trace_buffer *buffer,
 	int nr_loops = 0;
 	int add_ts_default;
 
-	/* ring buffer does cmpxchg, make sure it is safe in NMI context */
-	if (!IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) &&
+	/*
+	 * ring buffer does cmpxchg as well as atomic64 operations
+	 * (which some archs use locking for atomic64), make sure this
+	 * is safe in NMI context
+	 */
+	if ((!IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) ||
+	     IS_ENABLED(CONFIG_GENERIC_ATOMIC64)) &&
 	    (unlikely(in_nmi()))) {
 		return NULL;
 	}

Re: [BUG] spinlock recursion when enabling function tracer on 32-bit

[Ludwig Rydberg]

On 2024-12-20 16:05, Steven Rostedt wrote:
> On Fri, 20 Dec 2024 14:55:27 +0100
> Ludwig Rydberg <ludwig.rydberg@gaisler.com> wrote:
> 
>> On 2024-12-18 22:35, Steven Rostedt wrote:
>>
>>>
>>> Can you test this patch?
>>>   
Sure!

I've tested it and it works. But I had to modify the entry code for sparc32
to include nmi_{enter|exit} handling similar to irqentry_nmi_{enter|exit},
otherwise "in_nmi()" always returned false.

// Ludwig

Re: [BUG] spinlock recursion when enabling function tracer on 32-bit

[Ludwig Rydberg]

On 2024-12-20 16:05, Steven Rostedt wrote:

> 
> Can you try this patch on top of the last one?
> 

Hi Steven,

I just wanted to check if you saw my last reply to this thread.
I've tested both patches, and they work (tested on sparc32 and riscv32).

Let me know if you need more input.

Best regards,
// Ludwig

> 
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 7e257e855dd1..a9fe54b79ce5 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -4398,8 +4398,13 @@ rb_reserve_next_event(struct trace_buffer *buffer,
>  	int nr_loops = 0;
>  	int add_ts_default;
>  
> -	/* ring buffer does cmpxchg, make sure it is safe in NMI context */
> -	if (!IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) &&
> +	/*
> +	 * ring buffer does cmpxchg as well as atomic64 operations
> +	 * (which some archs use locking for atomic64), make sure this
> +	 * is safe in NMI context
> +	 */
> +	if ((!IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) ||
> +	     IS_ENABLED(CONFIG_GENERIC_ATOMIC64)) &&
>  	    (unlikely(in_nmi()))) {
>  		return NULL;
>  	}

Re: [BUG] spinlock recursion when enabling function tracer on 32-bit

[Steven Rostedt]

On Mon, 20 Jan 2025 15:41:47 +0100
Ludwig Rydberg <ludwig.rydberg@gaisler.com> wrote:

> I just wanted to check if you saw my last reply to this thread.
> I've tested both patches, and they work (tested on sparc32 and riscv32).
> 
> Let me know if you need more input.

No I missed your reply. I'll add the ring buffer code now, but the
generic code may need to go through another tree. I'll post both
patches and see what Linus thinks.

Thanks,

-- Steve