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=-2.1 required=3.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,T_DKIM_INVALID, URIBL_BLOCKED,USER_AGENT_MUTT 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 CC1B6C6778A for ; Mon, 9 Jul 2018 14:04:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6D36C20881 for ; Mon, 9 Jul 2018 14:04:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="BwkUPqed" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D36C20881 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk 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 S932855AbeGIOEl (ORCPT ); Mon, 9 Jul 2018 10:04:41 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:34038 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932827AbeGIOEi (ORCPT ); Mon, 9 Jul 2018 10:04:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=skY1rec6DbMsYEOSE0ejG2iW4tOc00qR+aKnb28opRQ=; b=BwkUPqedI0FQzRDRVeyaprCyE IAPYLm48aUP5NdJXGtw1q+M9Lqtp4Tb0T62JmFkNw0+3Sbrka+Ptf3k9U7TctQbgJ3PqVgQ6WlBIp iX6WBZ0lyB83Ewb+5hjkH2s50zPrLR48RyIl7ptZm7qF4T/zhv0hqTbhxZzwpaVZXBAp0=; Received: from n2100.armlinux.org.uk ([2002:4e20:1eda:1:214:fdff:fe10:4f86]:44450) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fcWmB-00064Q-1a; Mon, 09 Jul 2018 15:04:27 +0100 Received: from linux by n2100.armlinux.org.uk with local (Exim 4.90_1) (envelope-from ) id 1fcWm7-0001cA-0y; Mon, 09 Jul 2018 15:04:23 +0100 Date: Mon, 9 Jul 2018 15:04:21 +0100 From: Russell King - ARM Linux To: Alexey Brodkin Cc: linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arch@vger.kernel.org, Will Deacon , Peter Zijlstra , Boqun Feng , Arnd Bergmann , Thomas Gleixner , Ingo Molnar , Darren Hart , Shuah Khan , "Paul E. McKenney" , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , David Laight , Geert Uytterhoeven , Greg Kroah-Hartman Subject: Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Message-ID: <20180709140421.GF17271@n2100.armlinux.org.uk> References: <20180709124741.21037-1-abrodkin@synopsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180709124741.21037-1-abrodkin@synopsys.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 09, 2018 at 03:47:41PM +0300, Alexey Brodkin wrote: > 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. > > This came-up during lengthly discussion here: > http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004022.html > > Signed-off-by: Alexey Brodkin > Cc: Will Deacon > Cc: Peter Zijlstra > Cc: Boqun Feng > Cc: Russell King > Cc: Arnd Bergmann > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Darren Hart > Cc: Shuah Khan > Cc: "Paul E. McKenney" > Cc: Josh Triplett > Cc: Steven Rostedt > Cc: Mathieu Desnoyers > Cc: Lai Jiangshan > Cc: David Laight > Cc: Geert Uytterhoeven > Cc: Greg Kroah-Hartman > --- > arch/arm/include/asm/atomic.h | 2 +- > include/asm-generic/atomic64.h | 2 +- > include/linux/types.h | 4 ++-- > tools/include/linux/types.h | 2 +- > tools/testing/selftests/futex/include/atomic.h | 2 +- > .../rcutorture/formal/srcu-cbmc/include/linux/types.h | 4 ++-- > 6 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h > index 66d0e215a773..2ed6d7cf1407 100644 > --- a/arch/arm/include/asm/atomic.h > +++ b/arch/arm/include/asm/atomic.h > @@ -267,7 +267,7 @@ ATOMIC_OPS(xor, ^=, eor) > > #ifndef CONFIG_GENERIC_ATOMIC64 > typedef struct { > - long long counter; > + u64 __aligned(8) counter; > } atomic64_t; ARM doesn't need or require this change, and you're changing the type from signed to unsigned, which is likely to break stuff. So, NAK on this from the ARM point of view. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up