>Looking at the sched.h header file, it's pretty clear that this is there
>to protect against race conditions on SMP kernels. Which makes me
Exactly, I noticed the SMP race some week ago (see the thread SMP races
all over the place). You can find all the details on linux-kernel.
>wonder why you only changed that one line, but not all of the other
>lines in the driver which set current->state. Doing a quick grep over
I checked all drivers in the kernel and I changed _only_ the places which
needs the memory barrier to reduce the size of the patch.
All places that are using `current->state = ...' can be converted to
__set_current_state(...) of course, but that's only a coding issue and the
assembler generated will be the same. I am not worried by such conversion
since they are the same thing.
>Are there any circumstances where we should keep the old usage? Or
The old usage or __set_current_state() are the same thing. All places that
currently are not using set_current_state() _should_ continue with the
old usage or be converted to __set_current_state() (note the __).
If unsure set_current_state() is _always_ safe, but it will be slower than
__set_current_state. So if there's some kind of implicit memory barrier
between setting the task state and the read of the codition to break the
wait-event loop, then you can safely use __set_current_state().
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/