From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DBB6C6778A for ; Mon, 9 Jul 2018 13:29:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D6C9520878 for ; Mon, 9 Jul 2018 13:29:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D6C9520878 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754568AbeGIN3O convert rfc822-to-8bit (ORCPT ); Mon, 9 Jul 2018 09:29:14 -0400 Received: from smtp-out6.electric.net ([192.162.217.191]:64378 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750996AbeGIN3M (ORCPT ); Mon, 9 Jul 2018 09:29:12 -0400 Received: from 1fcWDv-0001zn-VS by out6a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fcWE0-0002gW-T3; Mon, 09 Jul 2018 06:29:08 -0700 Received: by emcmailer; Mon, 09 Jul 2018 06:29:07 -0700 Received: from [156.67.243.126] (helo=AcuMS.aculab.com) by out6a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fcWDv-0001zn-VS; Mon, 09 Jul 2018 06:29:03 -0700 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Jul 2018 14:30:43 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Mon, 9 Jul 2018 14:30:43 +0100 From: David Laight To: 'Alexey Brodkin' , "linux-kernel@vger.kernel.org" CC: "linux-snps-arc@lists.infradead.org" , "linux-arch@vger.kernel.org" , Will Deacon , Peter Zijlstra , Boqun Feng , Russell King , Arnd Bergmann , Thomas Gleixner , Ingo Molnar , Darren Hart , Shuah Khan , "Paul E. McKenney" , "Josh Triplett" , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Geert Uytterhoeven , "Greg Kroah-Hartman" Subject: RE: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Thread-Topic: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Thread-Index: AQHUF4NRoQYWMS2LoEe1JiahKnZsz6SG4gJw Date: Mon, 9 Jul 2018 13:30:43 +0000 Message-ID: <3d3ec70d99524a6fa7a38e7d2e0fdf98@AcuMS.aculab.com> References: <20180709124741.21037-1-abrodkin@synopsys.com> In-Reply-To: <20180709124741.21037-1-abrodkin@synopsys.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuMS.aculab.com X-TLS: TLSv1.2:ECDHE-RSA-AES256-SHA384:256 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Alexey Brodkin > Sent: 09 July 2018 13:48 > Atomic instructions require data they operate on to be aligned > according to data size. I.e. 32-bit atomic values must be 32-bit > aligned while 64-bit values must be 64-bit aligned. > > Otherwise even if CPU may handle not-aligend normal data access, > still atomic instructions fail and typically raise an exception > leaving us dead in the water. ... > diff --git a/include/asm-generic/atomic64.h b/include/asm-generic/atomic64.h > index 8d28eb010d0d..b94b749b5952 100644 > --- a/include/asm-generic/atomic64.h > +++ b/include/asm-generic/atomic64.h > @@ -13,7 +13,7 @@ > #define _ASM_GENERIC_ATOMIC64_H > > typedef struct { > - long long counter; > + u64 __aligned(8) counter; > } atomic64_t; Apart from the fact that this changes the value from signed to unsigned should most of the architectures be using this generic definition? The only exceptions would be 32bit architectures that lack 64bit instructions (eg m68k). David