Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751804AbdITP0L (ORCPT ); Wed, 20 Sep 2017 11:26:11 -0400 Received: from mail-io0-f169.google.com ([209.85.223.169]:43514 "EHLO mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751612AbdITP0K (ORCPT ); Wed, 20 Sep 2017 11:26:10 -0400 X-Google-Smtp-Source: AOwi7QASXRDqLGn/4PHwMkFDhj7ckr26Jrrd+2GNRUd5k03ubDaEK/TmCf3swGcHPOJQeS9g3Xw/XwY8gxAhmV/Pl7c= MIME-Version: 1.0 In-Reply-To: <20170920151802.7609-1-romain.izard.pro@gmail.com> References: <20170920151802.7609-1-romain.izard.pro@gmail.com> From: Ard Biesheuvel Date: Wed, 20 Sep 2017 08:26:09 -0700 Message-ID: Subject: Re: [PATCH] ARM: unaligned.h: Use an arch-specific version To: Romain Izard Cc: Russell King , Al Viro , Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3330 Lines: 93 Hi Romain, On 20 September 2017 at 08:18, Romain Izard wrote: > For the 32-bit ARM architecture, unaligned access support is variable. > On a chip without a MMU, an unaligned access returns a rotated data word > and must be avoided. > > When a MMU is available, it can be trapped. On ARMv6 or ARMv7, it can also > be handled by the hardware, depending on the type of access instruction. > Unaligned access of 32 bits or less are corrected, while larger access > provoke a trap. > > Unfortunately, the compiler is able to merge two 32-bit access that > would generate a LDR instruction, that works on unaligned access, into a > single LDM access that will not work. This is not a common situation, > but it has been observed in the LZ4 decompression code. > > To prevent this type of optimization, it is necessary to change the > explicit accessors for unaligned addresses from those defined in the > access_ok.h header, to those defined in the packed_struct.h header. > > Add an arch-specific header to ARM, to retain other optimizations that > rely on HAVE_EFFICIENT_UNALIGNED_ACCESS, while making sure that access > that explicitly rely on the unaligned accessors are correctly handled by > the compiler. > > Signed-off-by: Romain Izard > --- > If access_ok.h has been observed to produce different output from the struct versions (using any compiler), I guess we cannot simply change the asm-generic default and expect everybody to be ok with that. So I agree this is the most appropriate course of action. With the wart below removed: Acked-by: Ard Biesheuvel > This is a follow-up to this discussion: > HAVE_EFFICIENT_UNALIGNED_ACCESS on ARM32 > https://lkml.org/lkml/2017/9/4/359 > > arch/arm/include/asm/Kbuild | 1 - > arch/arm/include/asm/unaligned.h | 22 ++++++++++++++++++++++ > 2 files changed, 22 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/include/asm/unaligned.h > > diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild > index 721ab5ecfb9b..0f2c8a2a8131 100644 > --- a/arch/arm/include/asm/Kbuild > +++ b/arch/arm/include/asm/Kbuild > @@ -20,7 +20,6 @@ generic-y += simd.h > generic-y += sizes.h > generic-y += timex.h > generic-y += trace_clock.h > -generic-y += unaligned.h > > generated-y += mach-types.h > generated-y += unistd-nr.h > diff --git a/arch/arm/include/asm/unaligned.h b/arch/arm/include/asm/unaligned.h > new file mode 100644 > index 000000000000..394227f24b77 > --- /dev/null > +++ b/arch/arm/include/asm/unaligned.h > @@ -0,0 +1,22 @@ > +#ifndef __ASM_ARM_UNALIGNED_H > +#define __ASM_ARM_UNALIGNED_H > + > +#include > + > +#if defined(__LITTLE_ENDIAN) > +#include > +#include > +#include > +#define get_unaligned __get_unaligned_le > +#define put_unaligned __put_unaligned_le > +#elif defined(__BIG_ENDIAN) > +#include > :q ^^^ > +#include > +#include > +#define get_unaligned __get_unaligned_be > +#define put_unaligned __put_unaligned_be > +#else > +#error need to define endianness > +#endif > + > +#endif /* __ASM_ARM_UNALIGNED_H */ > -- > 2.11.0