Re: [PATCH] tracing: Remove pointless memory barriers

[Nam Cao <namcao@linutronix.de>]

On Thu, Jul 03, 2025 at 10:05:59AM +0200, Gabriele Monaco wrote:
> Hi all,
Hi Gabriele,

> these statements made me curious: I always thought of memory barriers as a way
> to order reads and writes to the same address across different CPUs (in other
> words, for visibility).
> 
> For instance I'd do something like:
> 
> CPU 1             CPU2
> 
> write(x)
> smp_mb()
>                   <implicit paired barrier>
>                   READ_ONCE(x)
> 
> Now, I get there isn't much we can do if reader and writer are racing, but, as
> Steve said, I'm expecting the presence of barriers to make the racing window
> smaller.
> 
> Am I misinterpreting the whole thing here? Are those barriers just ordering
> reads with reads and writes with writes (hence useful only with multiple
> variables)?

From "WHAT ARE MEMORY BARRIERS?" section in
https://www.kernel.org/doc/Documentation/memory-barriers.txt

    "Memory barriers [...] impose a perceived partial ordering over the
    memory operations on either side of the barrier."

and also have a look at "WHAT MAY NOT BE ASSUMED ABOUT MEMORY BARRIERS?"
later on:

    "There is no guarantee that any of the memory accesses specified before
    a memory barrier will be _complete_ by the completion of a memory
    barrier instruction"

Or data memory barrier explanation from Arm
(https://developer.arm.com/documentation/den0042/0100/Memory-Ordering/Memory-barriers)

    "This instruction ensures that all memory accesses in program order
    before the barrier are observed in the system before any explicit
    memory accesses that appear in program order after the barrier. It does
    not affect the ordering of any other instructions executing on the
    processor, or of instruction fetches."

So yes, smp_rmb() is only useful inbetween reads, and smp_wmb() is only
userful inbetween writes.

Best regards,
Nam