linux-kernel - Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers

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: <CAHk-=wjL803+FxtAPSGrWqThGQP5cCHzzwZJFq+-fkgt5DQ3VQ@mail.gmail.com>
Date: Thu, 26 Sep 2024 09:12:58 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Boqun Feng <boqun.feng@...il.com>, 
	linux-kernel@...r.kernel.org, rcu@...r.kernel.org, linux-mm@...ck.org, 
	lkmm@...ts.linux.dev, "Paul E. McKenney" <paulmck@...nel.org>, 
	Frederic Weisbecker <frederic@...nel.org>, Neeraj Upadhyay <neeraj.upadhyay@...nel.org>, 
	Joel Fernandes <joel@...lfernandes.org>, Josh Triplett <josh@...htriplett.org>, 
	Uladzislau Rezki <urezki@...il.com>, Steven Rostedt <rostedt@...dmis.org>, 
	Lai Jiangshan <jiangshanlai@...il.com>, Zqiang <qiang.zhang1211@...il.com>, 
	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>, 
	Waiman Long <longman@...hat.com>, Mark Rutland <mark.rutland@....com>, 
	Thomas Gleixner <tglx@...utronix.de>, Kent Overstreet <kent.overstreet@...il.com>, 
	Vlastimil Babka <vbabka@...e.cz>, maged.michael@...il.com, 
	Neeraj Upadhyay <neeraj.upadhyay@....com>
Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers

On Thu, 26 Sept 2024 at 08:54, Jonas Oberhauser
<jonas.oberhauser@...weicloud.com> wrote:
>
> No, the issue introduced by the compiler optimization (or by your
> original patch) is that the CPU can speculatively load from the first
> pointer as soon as it has completed the load of that pointer:

You mean the compiler can do it. The inline asm has no impact on what
the CPU does. The conditional isn't a barrier for the actual hardware.
But once the compiler doesn't try to do it, the data dependency on the
address does end up being an ordering constraint on the hardware too
(I'm happy to say that I haven't heard from the crazies that want
value prediction in a long time).

Just use a barrier.  Or make sure to use the proper ordered memory
accesses when possible. Don't use an inline asm for the compare - we
don't even have anything insane like that as a portable helper, and we
shouldn't have it.

                   Linus