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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
