Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Linus Torvalds <torvalds@osdl.org>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/