From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: [PATCHv2 02/10] kernel: Provide READ_ONCE and ASSIGN_ONCE Date: Tue, 25 Nov 2014 09:50:36 -0800 Message-ID: <20141125175036.GH5050@linux.vnet.ibm.com> References: <1416919117-50652-1-git-send-email-borntraeger@de.ibm.com> <1416919117-50652-3-git-send-email-borntraeger@de.ibm.com> <20141125155943.GB5050@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Linus Torvalds Cc: Christian Borntraeger , Linux Kernel Mailing List , "linux-arch@vger.kernel.org" , Paolo Bonzini , Ingo Molnar , Catalin Marinas , Will Deacon , Alexei Starovoitov , David Howells , Russell King List-Id: linux-arch.vger.kernel.org On Tue, Nov 25, 2014 at 09:28:33AM -0800, Linus Torvalds wrote: > On Tue, Nov 25, 2014 at 7:59 AM, Paul E. McKenney > wrote: > > > > We really need something like this to catch invalid sizes: > > > > default: invoke_nonexistent_function(); > > Actually, I wonder if we should make the default: case actually just > do something like > > barrier(); > memcpy(res, p, size); > barrier(); > > which in no way guarantees that it's an _atomic_ access, but it does > guarantee the semantics that you get one particular value and it won't > get reloaded later.. > > That would solve the crazy sparc pte issue too. I would be really worried about confusion due to load/store tearing, where a READ_ONCE() reads part of its value from one ASSIGN_ONCE() and the other part from some other ASSIGN_ONCE(). Don't get me wrong, there are cases where the load/store tearing is harmless, it is just that in my experience that these cases are anything but the common case. That said, I do not claim to be familiar with more than a microscopic fraction of the Linux kernel. Of course, one way to resolve this would be to have one variant that did the memcpy() and another that threw a build error, maybe READ_ONCE_FORCE() and ASSIGN_ONCE_FORC() or some such. I would -really- like to be informed if I do READ_ONCE() of a long long on a 32-bit system. ;-) /me goes off to see if there are any ACCESS_ONCE() of long longs in RCU... Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e33.co.us.ibm.com ([32.97.110.151]:35425 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750910AbaKYRum (ORCPT ); Tue, 25 Nov 2014 12:50:42 -0500 Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 25 Nov 2014 10:50:41 -0700 Date: Tue, 25 Nov 2014 09:50:36 -0800 From: "Paul E. McKenney" Subject: Re: [PATCHv2 02/10] kernel: Provide READ_ONCE and ASSIGN_ONCE Message-ID: <20141125175036.GH5050@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1416919117-50652-1-git-send-email-borntraeger@de.ibm.com> <1416919117-50652-3-git-send-email-borntraeger@de.ibm.com> <20141125155943.GB5050@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: Christian Borntraeger , Linux Kernel Mailing List , "linux-arch@vger.kernel.org" , Paolo Bonzini , Ingo Molnar , Catalin Marinas , Will Deacon , Alexei Starovoitov , David Howells , Russell King Message-ID: <20141125175036.vtmgs6n8hr9uPaIxUkXblYVqekKO7jFmV-B0M9JkTwk@z> On Tue, Nov 25, 2014 at 09:28:33AM -0800, Linus Torvalds wrote: > On Tue, Nov 25, 2014 at 7:59 AM, Paul E. McKenney > wrote: > > > > We really need something like this to catch invalid sizes: > > > > default: invoke_nonexistent_function(); > > Actually, I wonder if we should make the default: case actually just > do something like > > barrier(); > memcpy(res, p, size); > barrier(); > > which in no way guarantees that it's an _atomic_ access, but it does > guarantee the semantics that you get one particular value and it won't > get reloaded later.. > > That would solve the crazy sparc pte issue too. I would be really worried about confusion due to load/store tearing, where a READ_ONCE() reads part of its value from one ASSIGN_ONCE() and the other part from some other ASSIGN_ONCE(). Don't get me wrong, there are cases where the load/store tearing is harmless, it is just that in my experience that these cases are anything but the common case. That said, I do not claim to be familiar with more than a microscopic fraction of the Linux kernel. Of course, one way to resolve this would be to have one variant that did the memcpy() and another that threw a build error, maybe READ_ONCE_FORCE() and ASSIGN_ONCE_FORC() or some such. I would -really- like to be informed if I do READ_ONCE() of a long long on a 32-bit system. ;-) /me goes off to see if there are any ACCESS_ONCE() of long longs in RCU... Thanx, Paul