Re: [PATCH] tracing/snapshot: Avoid CPU buffer swap during reserve/commit

[Steven Rostedt]

On Thu, 30 Jul 2026 01:19:12 +0000
Tengda Wu <wutengda@xxxxxxxxxxxxxxx> wrote:

> Commit 3163f635b20e ("tracing: Fix race issue between cpu buffer write
> and swap") fixed most of the race conditions between snapshot's
> ring_buffer_swap_cpu and ring_buffer_lock_{reserve, commit}. It achieved
> this by replacing the asynchronous swap with smp_call_function_single to
> trigger an interrupt on the target CPU to handle the swap.

I'm curious. How did you discover this race?

> 
> However, this interrupt can still break in at any point during
> ring_buffer_lock_{reserve, commit}. Currently, ring_buffer_swap_cpu()
> relies on a cooperative check where cpu_buffer->committing is combined
> with a condition in rb_reserve_next_event() that verifies if
> READ_ONCE(cpu_buffer->buffer) != buffer to ensure state consistency. In
> principle, once the execution passes this conditional check, no issues
> should arise as long as cpu_buffer->committing remains non-zero.
> Unfortunately, there is a window where cpu_buffer->committing can drop
> to zero, which subsequently triggers a warning during rb_commit:
> 
>     ring_buffer_lock_reserve
>         cpu_buffer = buffer->buffers[cpu];       // cpu_buffer_a
>         rb_reserve_next_event
>             rb_start_commit // inc committing
>             if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) {...}
>             __rb_reserve_next
>                 rb_move_tail
>                     rb_end_commit(cpu_buffer);   // dec committing => 0
>                     /* smp_call interrupt hits here, successfully swaps! */
>                     local_inc(&cpu_buffer->committing);
> 
>     ring_buffer_unlock_commit
>         cpu_buffer = buffer->buffers[cpu];      // cpu_buffer_b
>         rb_commit
>             rb_end_commit
>             RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing))
>                                                 // triggers warning
> 
> Instead of maintaining fragile complexity to allow the swap to intervene at
> arbitrary points, simply replace smp_call_function_single with work_on_cpu.
> This ensures the swap operation runs in a process context on the target
> CPU, guaranteeing it only executes after ring_buffer_lock_{reserve, commit}
> has fully completed.

No this is not the answer. The issue is with the ring buffer swap code
but you band-aid in with a fix to the user of the code. The fix needs
to stay with the ring buffer. Yes that means it needs to handle the
case where an interrupt comes in at a page swap.

It needs to find another way to know that it's in the middle of that
swap, and return an -EBUSY from the interrupt.

-- Steve