[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231019085432.GQ33217@noisy.programming.kicks-ass.net>
Date: Thu, 19 Oct 2023 10:54:32 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Uros Bizjak <ubizjak@...il.com>, Nadav Amit <namit@...are.com>,
the arch/x86 maintainers <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...nel.org>,
Brian Gerst <brgerst@...il.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
"H . Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr()
On Wed, Oct 18, 2023 at 03:40:05PM -0700, Linus Torvalds wrote:
> Look at the *REAL* sequence counter code in <linux/seqlock.h>. Notice
> how in raw_read_seqcount_begin() we have
>
> unsigned _seq = __read_seqcount_begin(s);
> smp_rmb();
>
> because it actually does the proper barriers. Notice how the garbage
> code in __cyc2ns_read() doesn't have them - and how it was buggy as a
> result.
>
> (Also notice how this all predates our "we should use load_acquire()
> instead of smb_rmb()", but whatever).
seqlock actually wants rmb even today, the pattern is:
do {
seq = load-seq
rmb
load-data
rmb
} while (seq != re-load-seq)
we specifically only care about loads, and the data loads must be
between the sequence number loads.
As such, load-acquire is not a natural match.
Powered by blists - more mailing lists