On Wed, 6 Dec 2006, Christoph Lameter wrote:
>
> This means we tolerate the assignment race for SMP that was pointed out
> earlier?
The assignment "race" doesn't really exist in real code, I suspect.
There's two cases of assignment:
- pure initialization. This one isn't racy, since it's literally the
initial setting of some data structure, and if it's visible in
uninitialized state on other CPU's before being initialized, you have
bigger problems than some silly assignment race ;)
So the race doesn't exist for this class of assignment at all, and
that's the _common_ case of a pure assignment (ie the "we start out
with this field having value X")
- mixing assignment on one CPU (and not using "atomic_set()") and using
"cmpxchg()".
This would be a problem on architectures that use an external spinlock
or something, but I don't really see how it could be a valid code
sequence ANYWAY.
Any code that does this had better have some _higherlevel_
serialization around that data structure, since while it's not a _bug_
on architectures that do "cmpxchg()" in hardware (as far as the cmpxchg
itself is concerned), the fact is, in the absense of any other locking,
what the hell is such code supposed to _mean_?
In other words - the second case would be a bug in that it bypasses the
serialization of the spinlock, but why would you ever do that anyway? What
could _possibly_ be a valid use of such a "set value blindly" kind of
sequence? Since another CPU is clearly doing something to the value (ie
the cmpxchg), the "set it to value X" is just not a well-defined
operation in the first place, since you don't know what the end result is
(will it be "X", or will the "cmpxchg" on the other CPU have set it to
something else?).
So I don't think the race really exists for any sane code anyway. Even if
people don't use "atomic_set()".
But hey, maybe I'm just ignoring some really odd usage case.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
