linux-kernel - Re: [PATCH 17/17] RCU'd vfsmounts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Oct 2013 13:52:45 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 17/17] RCU'd vfsmounts

On Thu, Oct 3, 2013 at 1:41 PM, Al Viro <viro@...iv.linux.org.uk> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/