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] [day] [month] [year] [list]

Message-ID: <84o6uatn6i.fsf@jogness.linutronix.de>
Date: Thu, 26 Jun 2025 19:47:57 +0206
From: John Ogness <john.ogness@...utronix.de>
To: 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, Gabriele Monaco <gmonaco@...hat.com>
Subject: Re: [PATCH] tracing: Remove pointless memory barriers

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?

John Ogness