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

Reply via email to