From patchwork Fri Mar 4 11:14:24 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 63575 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp12066lbc; Fri, 4 Mar 2016 03:16:04 -0800 (PST) X-Received: by 10.66.100.196 with SMTP id fa4mr11146878pab.37.1457090164628; Fri, 04 Mar 2016 03:16:04 -0800 (PST) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id 21si5262287pfj.62.2016.03.04.03.16.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Mar 2016 03:16:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org; dkim=neutral (body hash did not verify) header.i=@linaro.org Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1abnh3-0005Fv-VX; Fri, 04 Mar 2016 11:14:49 +0000 Received: from mail-ig0-x231.google.com ([2607:f8b0:4001:c05::231]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1abngz-00050C-Ov for linux-arm-kernel@lists.infradead.org; Fri, 04 Mar 2016 11:14:47 +0000 Received: by mail-ig0-x231.google.com with SMTP id i18so16218917igh.1 for ; Fri, 04 Mar 2016 03:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fOOQjhfHOqKIEwYShHzdCE58q054jStUT2cXFca5rHw=; b=FsFkaNmYVHLOcTL+PUF0wEVmpjJdj38+bUJ7FueSAvLPd+VJliQ06IUTWLi/1pvfay ckhvSOYGy8KYIs67FLx5oClZn0r1I7ClyglK684HYUPFwUsyxmAklxdN0NWjDM3PQEpv +Bwp9aysDucXH4wsx1Lzp+fdToBu6RCdOxa+g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fOOQjhfHOqKIEwYShHzdCE58q054jStUT2cXFca5rHw=; b=AXxoRbr4mfnilsfW2odBCtrIfGWy1m06fwPLvM8Z6/IYT2z6iLdMcJA8Do+Tj0fXUM 4jOR2YNr0qLotaGecVB7mnQu1pFl+abLbTgeIAE6s3vNVDwaE7LfTnZMwTzmYehw7VT0 pxmd/Ygp+g1OMaedrqdbGcnNoEbe4uQOLup5ZXERFU6yJivS/tdoHUwGr1N9+Mv7qpJD /skHJm8B6nMHc/oBoCxpKKPsnFLFJWUsU8qu0o4ggorfm2zhRGMjvQe9KgcQLNK2C7rV c51YZVXykvW4IQWHVTVljcah+Q9BjA/xuQrUg70Gmn1+5+bjcoMbHxhEwZnut/FiN3U7 IghQ== X-Gm-Message-State: AD7BkJIu6JapB0WjGHU6jlNw9FYREH2zwdmM0vQ4KPwxVKO7sK0h23XodP7osOmMULG1K08wsLpaKk+dILd0whe0 MIME-Version: 1.0 X-Received: by 10.50.73.229 with SMTP id o5mr3766960igv.75.1457090065030; Fri, 04 Mar 2016 03:14:25 -0800 (PST) Received: by 10.36.29.6 with HTTP; Fri, 4 Mar 2016 03:14:24 -0800 (PST) In-Reply-To: <20160304110210.GA19428@n2100.arm.linux.org.uk> References: <56D8BA3F.7050508@pengutronix.de> <20160303235426.GA11237@arm.com> <20160304110210.GA19428@n2100.arm.linux.org.uk> Date: Fri, 4 Mar 2016 12:14:24 +0100 Message-ID: Subject: Re: DWord alignment on ARMv7 From: Ard Biesheuvel To: Russell King - ARM Linux X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160304_031445_909966_069452B4 X-CRM114-Status: GOOD ( 21.43 ) X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2607:f8b0:4001:c05:0:0:0:231 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marc Kleine-Budde , Will Deacon , "linux-arm-kernel@lists.infradead.org" , Arnd Bergmann Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org On 4 March 2016 at 12:02, Russell King - ARM Linux wrote: > On Fri, Mar 04, 2016 at 11:48:10AM +0100, Ard Biesheuvel wrote: >> I don't think it is the job of the filesystem driver to reason about >> whether get_unaligned_le64() does the right thing under any particular >> configuration. If ARM's implementation of get_unaligned_le64() issues >> load instructions that result in a trap, it is misbehaving and should >> be fixed. > > It's not ARMs implementation, we don't have our own implementation, but > we seem to (today) use asm-generic stuff, which is sub-optimal. > Indeed. I was not suggesting that ARM carries broken code, simply that btrfs should not have to worry that it gets built on a platform that requires extra care when invoking get_unaligned_le64() > Looking at the state of that, I guess we need to implement our own > asm/unaligned.h - and as the asm-generic stuff assumes that all > access sizes fall into the same categories, I'm guessing we'll need > to implement _all_ accessors ourselves. > > That really sounds very sub-optimal, but I don't see any other solution > which wouldn't make the asm-generic stuff even more painful to follow > through multiple include files than it already is today. > I wonder if we should simply apply something like the patch below (untested): it depends on how many 32-bit architectures implement double word load instructions, but for ones that don't, the patch shouldn't change anything, nor should it change anything for 64-bit architectures. -------8<----------- _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/include/linux/unaligned/access_ok.h b/include/linux/unaligned/access_ok.h index 99c1b4d20b0f..019d0b7ea6a3 100644 --- a/include/linux/unaligned/access_ok.h +++ b/include/linux/unaligned/access_ok.h @@ -16,7 +16,11 @@ static inline u32 get_unaligned_le32(const void *p) static inline u64 get_unaligned_le64(const void *p) { - return le64_to_cpup((__le64 *)p); + if (BITS_PER_LONG == 64) + return le64_to_cpup((__le64 *)p); + else + return ((u64)le32_to_cpup((__le32 *)p)) | + ((u64)le32_to_cpup((__le32 *)p + 1) << 32); } static inline u16 get_unaligned_be16(const void *p) @@ -31,7 +35,11 @@ static inline u32 get_unaligned_be32(const void *p) static inline u64 get_unaligned_be64(const void *p) { - return be64_to_cpup((__be64 *)p); + if (BITS_PER_LONG == 64) + return be64_to_cpup((__be64 *)p); + else + return ((u64)be32_to_cpup((__be32 *)p) << 32) | + ((u64)be32_to_cpup((__be32 *)p + 1)); } static inline void put_unaligned_le16(u16 val, void *p) @@ -46,7 +54,12 @@ static inline void put_unaligned_le32(u32 val, void *p) static inline void put_unaligned_le64(u64 val, void *p) { - *((__le64 *)p) = cpu_to_le64(val); + if (BITS_PER_LONG == 64) { + *((__le64 *)p) = cpu_to_le64(val); + } else { + *((__le32 *)p) = cpu_to_le32(val); + *((__le32 *)p + 1) = cpu_to_le32(val >> 32); + } } static inline void put_unaligned_be16(u16 val, void *p) @@ -61,7 +74,12 @@ static inline void put_unaligned_be32(u32 val, void *p) static inline void put_unaligned_be64(u64 val, void *p) { - *((__be64 *)p) = cpu_to_be64(val); + if (BITS_PER_LONG == 64) { + *((__be64 *)p) = cpu_to_be64(val); + } else { + *((__be32 *)p) = cpu_to_le32(val >> 32); + *((__be32 *)p + 1) = cpu_to_le32(val); + } } #endif /* _LINUX_UNALIGNED_ACCESS_OK_H */