HAVE_EFFICIENT_UNALIGNED_ACCESS on ARM32 (was: Alignment issues in zImage with Linux 4.12, LZ4 and GCC5.3)

On 6 September 2017 at 23:38, Arnd Bergmann [off-list ref] wrote:

On Thu, Sep 7, 2017 at 12:23 AM, Ard Biesheuvel
[off-list ref] wrote:

quoted

On 6 September 2017 at 21:57, Arnd Bergmann [off-list ref] wrote:

quoted

On Mon, Sep 4, 2017 at 6:19 PM, Romain Izard [off-list ref] wrote:

HAVE_EFFICIENT_UNALIGNED_ACCESS only affects explicit unaligned
accesses, and selects between fixups in hardware or in software.
AFAICT the issue here is implicit unaligned accesses, where char
pointers are passed as u32 * arguments.

The problem with include/linux/unaligned/access_ok.h is that it
converts pointers
that are known by the caller to be potentially unaligned and accesses them as if
they were aligned. This means we require a software fixup through the
trap handler
on ARM in cases that the compiler already knows how to handle correctly when
using linux/unaligned/le_struct.h. On ARMv7 this means it ends up using normal
load/store instructures but not the ldm/stm or ldrd/stdr instructions
that are not
allowed on unaligned pointers.

Ah ok, I missed that part. The distinction between ldr/str and
ldm/stm/ldrd is a bit fiddly, but if we can solve this using C code, I
am all for it.

Doing that solves the problem that Romain ran into and also makes other
code much more efficient on ARMv7.

It is not entirely clear to me why casting to a pointer-to-struct type
makes any difference here. Is it simply because of the __packed
attribute?

Anyway, the issue I spotted in the LZ4 code did not use unaligned
accessors at all, so we must be talking about different things here.
But perhaps the solution there is to simply update that code to use
these accessors in places where such casts are being done. If we then
compile the decompressor with -mno-unaligned-access (which we should
be doing already in any case), these issues should be eliminated.