On Sat, 2008-11-01 at 00:42 +0800, Chris Snook wrote:Huang Ying wrote:Hi, Chris,atomic_read() and atomic_set() don't inherently cause changes to be visible on other CPUs any faster than ++ and -- operators. Sometimes it happens to work out that way as a result of how the compiler and the CPU order operations, but there's no semantic guarantee, and it could even take arbitrarily long under some circumstances. If you want to use atomic ops to close the race, you need to use barriers.
On Wed, 2008-10-29 at 08:51 -0600, Chris Snook wrote:Huang Ying wrote:I don't think that is necessary. I haven't found there is particularFix a race condition accessing oops_in_progress. Which may be changed onYou also need barriers. I believe rmb() before atomic_read() and wmb() after atomic_set() should suffice.
multiple CPU simultaneously, but it is changed via non-atomic operation
++/--. This patch changes the definition of oops_in_process from int to
atomic_t, and accessing method to atomic operations.
consistent requirement about oops_in_progress.
As far as I know, barriers don't cause changes to be visible on other
CPUs faster too. It just guarantees corresponding operations after will
not get executed until that before have finished. And, I don't think we
need make changes to be visible on other CPUs faster.