From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751961AbaKXU2Q (ORCPT ); Mon, 24 Nov 2014 15:28:16 -0500 Received: from e06smtp15.uk.ibm.com ([195.75.94.111]:57166 "EHLO e06smtp15.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751849AbaKXU2O (ORCPT ); Mon, 24 Nov 2014 15:28:14 -0500 Message-ID: <547394D5.4020301@de.ibm.com> Date: Mon, 24 Nov 2014 21:28:05 +0100 From: Christian Borntraeger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: paulmck@linux.vnet.ibm.com, Linus Torvalds CC: Alexei Starovoitov , David Howells , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , linux-mips , linux-x86_64@vger.kernel.org, linux-s390 , Paolo Bonzini , Ingo Molnar , Catalin Marinas , Will Deacon Subject: Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types References: <1416834210-61738-1-git-send-email-borntraeger@de.ibm.com> <1416834210-61738-8-git-send-email-borntraeger@de.ibm.com> <15567.1416835858@warthog.procyon.org.uk> <547381D7.2070404@de.ibm.com> <20141124194200.GR5050@linux.vnet.ibm.com> In-Reply-To: <20141124194200.GR5050@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14112420-0021-0000-0000-000001E54CAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 24.11.2014 um 20:42 schrieb Paul E. McKenney: > On Mon, Nov 24, 2014 at 11:14:42AM -0800, Linus Torvalds wrote: >> On Mon, Nov 24, 2014 at 11:07 AM, Christian Borntraeger >> wrote: >>> >>> Looks really nice, but does not work with ACCESS_ONCE is on the left-hand side: >> >> Oh, I forgot about that. And that was indeed why I had done that whole >> helper macro originally, with ACCESS_ONCE() itself just being the >> dereference of the pointer. > > OK, how about the following? > > It complains if the variable is too large, for example, long long on > 32-bit systems or large structures. It is OK loading from and storing > to small structures as well, which I am having a hard time thinking of > as a disadvantage. Well, the motivation for this series was that gcc 4.6 and 4.7 might ignore volatile for such a case, see the original thread and this data structure union ipte_control { unsigned long val; struct { unsigned long k : 1; unsigned long kh : 31; unsigned long kg : 32; }; }; > ------------------------------------------------------------------------ > > #define get_scalar_volatile_pointer(x) ({ \ > volatile typeof(x) *__vp = &(x); \ > BUILD_BUG_ON(sizeof(*__vp) != sizeof(char) && \ > sizeof(*__vp) != sizeof(short) && \ > sizeof(*__vp) != sizeof(int) && \ > sizeof(*__vp) != sizeof(long)); \ > __vp; }) > #define ACCESS_ONCE(x) (*get_scalar_volatile_pointer(x)) > This gives also several compiler errors when accessing u64 on a 32bit system. This is expected, but more widespread than expected - ouch. Christian