![]() |
|
Message-ID: <15734b32cecddde7905d3a97005a0c883383cc74.camel@surriel.com> Date: Sun, 09 Feb 2025 20:09:51 -0500 From: Rik van Riel <riel@...riel.com> To: Linus Torvalds <torvalds@...ux-foundation.org>, David Laight <david.laight.linux@...il.com> Cc: x86@...nel.org, linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, Catalin Marinas <catalin.marinas@....com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Josh Poimboeuf <jpoimboe@...hat.com>, Andi Kleen <ak@...ux.intel.com>, Dan Williams <dan.j.williams@...el.com>, linux-arch@...r.kernel.org, Kees Cook <keescook@...omium.org>, kernel-hardening@...ts.openwall.com, "Paul E.McKenney" <paulmck@...nel.org> Subject: Re: [PATCH 1/1] x86: In x86-64 barrier_nospec can always be lfence On Sun, 2025-02-09 at 13:57 -0800, Linus Torvalds wrote: > > So on x86, both read and write barriers are complete no-ops, because > all reads are ordered, and all writes are ordered. Given that this thread started with a reference to rdtsc, it may be worth keeping in mind that rdtsc reads themselves do not always appear to be ordered. Paul and I spotted some occasionaly "backwards TSC values" from the CSD lock instrumentation code, which went away when using ordered TSC reads: https://lkml.iu.edu/hypermail/linux/kernel/2410.1/03202.html I guess maybe a TSC read does not follow all the same rules as a memory read, sometimes? -- All Rights Reversed.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.