[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <053a199934844aef9745d7398494b5a0@AcuMS.aculab.com>
Date: Mon, 16 Dec 2019 17:45:22 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Andy Lutomirski' <luto@...nel.org>
CC: Peter Zijlstra <peterz@...radead.org>,
"Luck, Tony" <tony.luck@...el.com>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
Ingo Molnar <mingo@...nel.org>,
"Thomas Gleixner" <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"Borislav Petkov" <bp@...en8.de>, H Peter Anvin <hpa@...or.com>,
"Raj, Ashok" <ashok.raj@...el.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
x86 <x86@...nel.org>, "Will Deacon" <will@...nel.org>
Subject: RE: [PATCH v10 6/6] x86/split_lock: Enable split lock detection by
kernel parameter
From: Andy Lutomirski
> Sent: 16 December 2019 17:23
...
> I'm talking specifically about x86 here, where, for example, "Reads
> are not reordered with other reads". So READ_ONCE *does* have
> sequencing requirements on the CPUs.
>
> Feel free to replace READ_ONCE with MOV in your head if you like :)
I got a little confused because I thought your reference to READ_ONCE()
was relevant.
Sometimes remembering all this gets hard.
The docs about the effects of LFENCE and MFENCE don't really help
(they make my brain hurt).
I'm pretty sure I've decided in the past they are almost never needed.
Usually the ordering of reads doesn't help you.
IIRC If locations 'a' and 'b' get changed from 0 to 1 it is perfectly possible
for one cpu to see a==0, b==1 and another a==1, b==0 even
though both read a then b.
(On non-alpha this may require different cpus update a and b.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists