linux-kernel - Re: [PATCH] tracing: Remove pointless memory barriers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250708074219.K7BthlGg@linutronix.de>
Date: Tue, 8 Jul 2025 09:42:19 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: John Ogness <john.ogness@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tracing: Remove pointless memory barriers

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