Re: [PATCH 17/17] RCU'd vfsmounts

[Linus Torvalds]

On Thu, Oct 3, 2013 at 1:41 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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.

                  Linus
--
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/