public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* smp_store_mb() oddity..
@ 2015-07-01 16:39 Linus Torvalds
  2015-07-01 17:17 ` Peter Zijlstra
  0 siblings, 1 reply; 4+ messages in thread
From: Linus Torvalds @ 2015-07-01 16:39 UTC (permalink / raw)
  To: Peter Zijlstra, Ingo Molnar; +Cc: Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-07-02 22:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-01 16:39 smp_store_mb() oddity Linus Torvalds
2015-07-01 17:17 ` Peter Zijlstra
2015-07-02  5:40   ` Heiko Carstens
2015-07-02 22:29   ` Benjamin Herrenschmidt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox