lkml.org 
[lkml]   [2015]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
Subjectsmp_store_mb() oddity..
From
Peter/Ingo,
while resolving a conflict, I noticed that we have the generic
default definition of "smp_store_mb()" be:

do { WRITE_ONCE(var, value); mb(); } while (0)

which looks pretty odd. Why? That "mb()" is a full memory barrier even
on UP, yet this is clearly a smp barrier.

So I think that "mb()" should be "smp_mb()". Looking at other
architecture definitions, most architectures already do that.

I think this is just left-over from our previous (badly specified)
"set_mb()", and that commit b92b8b35a2e3 ("locking/arch: Rename
set_mb() to smp_store_mb()") just didn't notice. Our old set_mb()
was already confused about whether it was a smp barrier or an IO
barrier (eg ARM uses smp_mb, x86 has separate smp/up versions, but
others dop the unconditional memory barrier).

I didn't change this in the merge, because it's not just the generic
version where the conflict was, there's also powerpc, s390 and ia64
that still have the non-smp version too. But some locking person
should probably clean this up... Hint hint,

Linus


\
 
 \ /
  Last update: 2015-07-01 19:01    [W:0.065 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site