lkml.org 
[lkml]   [2019]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v10 6/6] x86/split_lock: Enable split lock detection by kernel parameter
On Mon, Dec 16, 2019 at 9:45 AM David Laight <David.Laight@aculab.com> wrote:
>
> 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.
>

Me too.

This whole discussion is about the fact that PeterZ is sceptical that
actual x86 CPUs have as strong a memory model as the SDM suggests, and
I'm trying to understand the exact concern. This may or may not be
directly relevant to the kernel. :)

> 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.)
>

x86 mostly prevents this.

\
 
 \ /
  Last update: 2019-12-16 19:37    [W:0.121 / U:1.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site