Messages in this thread | | | Subject | Re: [PATH -mm -v2] Fix a race condtion of oops_in_progress | From | Huang Ying <> | Date | Mon, 03 Nov 2008 09:52:41 +0800 |
| |
On Sat, 2008-11-01 at 00:42 +0800, Chris Snook wrote: > 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.
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.
Best Regards, Huang Ying
[unhandled content-type:application/pgp-signature] | |