Re: [PATCH] tracing: Remove pointless memory barriers

[John Ogness <john.ogness@linutronix.de>]

Hi Steven,

On 2025-06-26, Steven Rostedt <rostedt@goodmis.org> wrote:
>> Your scenario can still happen despite the memory barrier:
>
> Yes, but the point isn't really to prevent the race. It's more about making
> the race window smaller.
>
> When we disable it, if something is currently using it then it may or may
> not get in. That's fine as this isn't critical.
>
> But from my understanding, without the barriers, some architectures may
> never see the update. That is, the write from one CPU may not get to memory
> for a long time and new incoming readers will still see the old data. I'm
> more concerned with new readers than ones that are currently racing with
> the updates.

Memory barriers do not affect visibility. They only affect ordering. And
ordering implies that there are at least 2 pieces of data involved. A
memory barrier has no meaning when you are only talking about 1 piece of
data (in this case @buffer_disabled).

For example, update_traceon_count() has an smp_rmb()/smp_wmb() pair to
make sure @count updates are ordered to be after @buffer_disabled
updates.

read(count)
smp_rmb()
read(buffer_disabled)

write(buffer_disabled)
smp_wmb()
write(count)

But what exactly are the memory barriers removed in this patch ordering?

John Ogness