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: <564f10574f11bd7ca42fcc5fb4d6c5625dc17205.camel@redhat.com>
Date: Thu, 03 Jul 2025 10:05:59 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: John Ogness <john.ogness@...utronix.de>, Steven Rostedt
	 <rostedt@...dmis.org>, Nam Cao <namcao@...utronix.de>
Cc: 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, 2025-06-26 at 19:47 +0206, John Ogness wrote:
> Hi Steven,
> 
> On 2025-06-26, Steven Rostedt <rostedt@...dmis.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?
> 

Hi all,

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)?

Thanks,
Gabriele