Re: [PATH -mm -v2] Fix a race condtion of oops_in_progress
From: Chris Snook
Date: Fri Oct 31 2008 - 12:42:30 EST
Huang Ying wrote:
Hi, Chris,
On Wed, 2008-10-29 at 08:51 -0600, Chris Snook wrote:
Huang Ying wrote:
Fix a race condition accessing oops_in_progress. Which may be changed on
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.
You also need barriers. I believe rmb() before atomic_read() and wmb() after
atomic_set() should suffice.
I don't think that is necessary. I haven't found there is particular
consistent requirement about oops_in_progress.
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.
-- Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/