From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: [RFC][PATCH 0/5] arch: atomic rework Date: Sun, 23 Feb 2014 20:59:51 -0800 Message-ID: <20140224045951.GH8264@linux.vnet.ibm.com> References: <1392922421.28840.36.camel@triegel.csb> <1393095223.28840.4914.camel@triegel.csb> <20140223003933.GQ4250@linux.vnet.ibm.com> <20140223063426.GT4250@linux.vnet.ibm.com> <20140224011651.GC8264@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Content-Disposition: inline In-Reply-To: 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" List-Id: linux-arch.vger.kernel.org On Sun, Feb 23, 2014 at 05:35:28PM -0800, Linus Torvalds wrote: > On Sun, Feb 23, 2014 at 5:16 PM, Paul E. McKenney > wrote: > >> > >> (a) we've said 'q' is restricted, so there is no aliasing between q > >> and the pointers b/c. So the compiler is free to move those accesses > >> around the "q = p->next" access. > > > > Ah, if I understand you, very good! > > > > My example intentionally left "q" -not- restricted. > > No, I 100% agree with that. "q" is *not* restricted. But "p" is, since > it came from that consuming load. > > But "q = p->next" is ordered by how something can alias "p->next", not by 'q'! > > There is no need to restrict anything but 'p' for all of this to work. I cannot say I understand this last sentence right new from the viewpoint of the standard, but suspending disbelief for the moment... (And yes, given current compilers and CPUs, I agree that this should all work in practice. My concern is the legality, not the reality.) > Btw, it's also worth pointing out that I do *not* in any way expect > people to actually write the "restrict" keyword anywhere. So no need > to change source code. Understood -- in this variant, you are taking the marking from the fact that there was an assignment from a memory_order_consume load rather than from a keyword on the assigned-to variable's declaration. > What you have is a situation where the pointer coming out of the > memory_order_consume is restricted. But if you assign it to a > non-restricted pointer, that's *fine*. That's perfectly normal C > behavior. The "restrict" concept is not something that the programmer > needs to worry about or ever even notice, it's basically just a > promise to the compiler that "if somebody has another pointer lying > around, accesses though that other pointer do not require ordering". > > So it sounds like you believe that the programmer would mark things > "restrict", and I did not mean that at all. Indeed I did believe that. I must confess that I was looking for an easy way to express in standardese -exactly- where the ordering guarantee did and did not propagate. The thing is that the vast majority of the Linux-kernel RCU code is more than happy with the guarantee only applying to fetches via the pointer returned from the memory_order_consume load. There are relatively few places where groups of structures are made visible to RCU readers via a single rcu_assign_pointer(). I guess I need to actually count them. Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e35.co.us.ibm.com ([32.97.110.153]:49015 "EHLO e35.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751716AbaBXE77 (ORCPT ); Sun, 23 Feb 2014 23:59:59 -0500 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 23 Feb 2014 21:59:59 -0700 Date: Sun, 23 Feb 2014 20:59:51 -0800 From: "Paul E. McKenney" Subject: Re: [RFC][PATCH 0/5] arch: atomic rework Message-ID: <20140224045951.GH8264@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1392922421.28840.36.camel@triegel.csb> <1393095223.28840.4914.camel@triegel.csb> <20140223003933.GQ4250@linux.vnet.ibm.com> <20140223063426.GT4250@linux.vnet.ibm.com> <20140224011651.GC8264@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: 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" Message-ID: <20140224045951.qGx63E0UgnPtqp3-0XSX06dZaBJXqu45w_c2Edfy2N4@z> On Sun, Feb 23, 2014 at 05:35:28PM -0800, Linus Torvalds wrote: > On Sun, Feb 23, 2014 at 5:16 PM, Paul E. McKenney > wrote: > >> > >> (a) we've said 'q' is restricted, so there is no aliasing between q > >> and the pointers b/c. So the compiler is free to move those accesses > >> around the "q = p->next" access. > > > > Ah, if I understand you, very good! > > > > My example intentionally left "q" -not- restricted. > > No, I 100% agree with that. "q" is *not* restricted. But "p" is, since > it came from that consuming load. > > But "q = p->next" is ordered by how something can alias "p->next", not by 'q'! > > There is no need to restrict anything but 'p' for all of this to work. I cannot say I understand this last sentence right new from the viewpoint of the standard, but suspending disbelief for the moment... (And yes, given current compilers and CPUs, I agree that this should all work in practice. My concern is the legality, not the reality.) > Btw, it's also worth pointing out that I do *not* in any way expect > people to actually write the "restrict" keyword anywhere. So no need > to change source code. Understood -- in this variant, you are taking the marking from the fact that there was an assignment from a memory_order_consume load rather than from a keyword on the assigned-to variable's declaration. > What you have is a situation where the pointer coming out of the > memory_order_consume is restricted. But if you assign it to a > non-restricted pointer, that's *fine*. That's perfectly normal C > behavior. The "restrict" concept is not something that the programmer > needs to worry about or ever even notice, it's basically just a > promise to the compiler that "if somebody has another pointer lying > around, accesses though that other pointer do not require ordering". > > So it sounds like you believe that the programmer would mark things > "restrict", and I did not mean that at all. Indeed I did believe that. I must confess that I was looking for an easy way to express in standardese -exactly- where the ordering guarantee did and did not propagate. The thing is that the vast majority of the Linux-kernel RCU code is more than happy with the guarantee only applying to fetches via the pointer returned from the memory_order_consume load. There are relatively few places where groups of structures are made visible to RCU readers via a single rcu_assign_pointer(). I guess I need to actually count them. Thanx, Paul