Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752143AbaB0UxS (ORCPT ); Thu, 27 Feb 2014 15:53:18 -0500 Received: from e39.co.us.ibm.com ([32.97.110.160]:35400 "EHLO e39.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751326AbaB0UxR (ORCPT ); Thu, 27 Feb 2014 15:53:17 -0500 Date: Thu, 27 Feb 2014 12:53:12 -0800 From: "Paul E. McKenney" To: Linus Torvalds 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" Subject: Re: [RFC][PATCH 0/5] arch: atomic rework Message-ID: <20140227205312.GX8264@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20140224172110.GO8264@linux.vnet.ibm.com> <20140224185341.GU8264@linux.vnet.ibm.com> <1393515453.28840.9961.camel@triegel.csb> <20140227190611.GU8264@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14022720-9332-0000-0000-0000033F2DFA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 27, 2014 at 11:47:08AM -0800, Linus Torvalds wrote: > 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? I can make a contrived litmus test for it, but you are right, the only time you can see it happen is when X has no barriers, in which case you don't have any ordering anyway -- both the compiler and the CPU can reorder the loads into p and q, and the read from p->val can, as you say, come from either pointer. For whatever it is worth, hear is the litmus test: T1: p = kmalloc(...); if (p == NULL) deal_with_it(); p->a = 42; /* Each field in its own cache line. */ p->b = 43; p->c = 44; atomic_store_explicit(&gp1, p, memory_order_release); p->b = 143; p->c = 144; atomic_store_explicit(&gp2, p, memory_order_release); T2: p = atomic_load_explicit(&gp2, memory_order_consume); r1 = p->b; /* Guaranteed to get 143. */ q = atomic_load_explicit(&gp1, memory_order_consume); if (p == q) { /* The compiler decides that q->c is same as p->c. */ r2 = p->c; /* Could get 44 on weakly order system. */ } The loads from gp1 and gp2 are, as you say, unordered, so you get what you get. And publishing a structure via one RCU-protected pointer, updating it, then publishing it via another pointer seems to me to be asking for trouble anyway. If you really want to do something like that and still see consistency across all the fields in the structure, please put a lock in the structure and use it to guard updates and accesses to those fields. Thanx, Paul -- 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/