lkml.org 
[lkml]   [2008]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATH -mm -v2] Fix a race condtion of oops_in_progress
    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


    \
     
     \ /
      Last update: 2008-10-31 17:45    [W:0.023 / U:31.256 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site