[lkml]   [2013]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 17/17] RCU'd vfsmounts
    On Thu, Oct 3, 2013 at 1:41 PM, Al Viro <> wrote:
    > The problem is this:
    > A = 1, B = 1
    > CPU1:
    > A = 0
    > <full barrier>
    > synchronize_rcu()
    > read B
    > CPU2:
    > rcu_read_lock()
    > B = 0
    > read A
    > Are we guaranteed that we won't get both of them seeing ones, in situation
    > when that rcu_read_lock() comes too late to be noticed by synchronize_rcu()?

    Yeah, I think we should be guaranteed that, because the
    synchronize_rcu() will guarantee that all other CPU's go through an
    idle period. So the "read A" on CPU2 cannot possibly see a 1 _unless_
    it happens so early that synchronize_rcu() definitely sees it (ie it's
    a "preexisting reader" by definition), in which case synchronize_rcu()
    will be waiting for a subsequent idle period, in which case the B=0 on
    CPU2 is not only guaranteed to happen but also be visible out, so the
    "read B" on CPU1 will see 0. And that's true even if CPU2 doesn't have
    an explicit memory barrier, because the "RCU idle" state implies that
    it has gone through a barrier.

    So I don't see how they could possibly see ones. Modulo terminal bugs
    in synchronize_barrier() (which can be very slow, but for umount I
    wouldn't worry). Or modulo my brain being fried.


     \ /
      Last update: 2013-10-03 23:01    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean