Re: [PATCH] tracing: Remove pointless memory barriers

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 26 Jun 2025 18:04:59 +0200
Nam Cao <namcao@linutronix.de> wrote:

> I think you have it inverted? I assume you meant:
> 
> "Without the barriers, the tr->buffer_disabled = 1 can be set on one CPU,
> and the other CPU can think the buffer is still enabled and do work that
> will end up doing nothing."
> 
> 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.

> 
> CPU1                          CPU2
>                               smp_rb()
>                               read buffer_disabled, see 0 --> let's do work!
> buffer_disabled=1
> smp_wb()
>                               do work -> end up doing nothing
> 
> >From my understanding, smp_wb()'s purpose is ensuring the ordering of one  
> write and another write, e.g.:
>     write(a)
>     smp_wb()
>     write(b)
> 
> For our case, there is only a single write. Therefore I don't think
> smp_wb() is useful.

Well, it does make it visible for other CPUs that do not have strong cache
coherency.

-- Steve