Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753025AbaB0TrX (ORCPT ); Thu, 27 Feb 2014 14:47:23 -0500 Received: from mail-ve0-f177.google.com ([209.85.128.177]:41432 "EHLO mail-ve0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752512AbaB0TrR (ORCPT ); Thu, 27 Feb 2014 14:47:17 -0500 MIME-Version: 1.0 In-Reply-To: <20140227190611.GU8264@linux.vnet.ibm.com> References: <20140223063426.GT4250@linux.vnet.ibm.com> <20140224172110.GO8264@linux.vnet.ibm.com> <20140224185341.GU8264@linux.vnet.ibm.com> <1393515453.28840.9961.camel@triegel.csb> <20140227190611.GU8264@linux.vnet.ibm.com> Date: Thu, 27 Feb 2014 11:47:08 -0800 X-Google-Sender-Auth: qWeWZ-q6hLQsPhjuQQhImg6TCwU Message-ID: Subject: Re: [RFC][PATCH 0/5] arch: atomic rework From: Linus Torvalds To: Paul McKenney Cc: Torvald Riegel , Will Deacon , Peter Zijlstra , Ramana Radhakrishnan , David Howells , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "mingo@kernel.org" , "gcc@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney wrote: > > 3. The comparison was against another RCU-protected pointer, > where that other pointer was properly fetched using one > of the RCU primitives. Here it doesn't matter which pointer > you use. At least as long as the rcu_assign_pointer() for > that other pointer happened after the last update to the > pointed-to structure. > > I am a bit nervous about #3. Any thoughts on it? I think that it might be worth pointing out as an example, and saying that code like p = atomic_read(consume); X; q = atomic_read(consume); Y; if (p == q) data = p->val; then the access of "p->val" is constrained to be data-dependent on *either* p or q, but you can't really tell which, since the compiler can decide that the values are interchangeable. I cannot for the life of me come up with a situation where this would matter, though. If "X" contains a fence, then that fence will be a stronger ordering than anything the consume through "p" would guarantee anyway. And if "X" does *not* contain a fence, then the atomic reads of p and q are unordered *anyway*, so then whether the ordering to the access through "p" is through p or q is kind of irrelevant. No? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/