[PATCH] ARM: add a private asm/unaligned.h
Gregory CLEMENT
gregory.clement at free-electrons.com
Mon Oct 30 08:05:49 PDT 2017
Hi Ard,
On lun., oct. 30 2017, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 30 October 2017 at 13:48, Gregory CLEMENT
> <gregory.clement at free-electrons.com> wrote:
>> Hi Russell,
>>
>> On ven., oct. 27 2017, Russell King - ARM Linux <linux at armlinux.org.uk> wrote:
>>
>>> On Fri, Oct 27, 2017 at 05:19:55PM +0200, Gregory CLEMENT wrote:
>>>> Hi Arnd,
>>>>
>>>> On ven., oct. 20 2017, Arnd Bergmann <arnd at arndb.de> wrote:
>>>>
>>>> > The asm-generic/unaligned.h header provides two different implementations
>>>> > for accessing unaligned variables: the access_ok.h version used when
>>>> > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set pretends that all pointers
>>>> > are in fact aligned, while the le_struct.h version convinces gcc that the
>>>> > alignment of a pointer is '1', to make it issue the correct load/store
>>>> > instructions depending on the architecture flags.
>>>> >
>>>> > On ARMv5 and older, we always use the second version, to let the compiler
>>>> > use byte accesses. On ARMv6 and newer, we currently use the access_ok.h
>>>> > version, so the compiler can use any instruction including stm/ldm and
>>>> > ldrd/strd that will cause an alignment trap. This trap can significantly
>>>> > impact performance when we have to do a lot of fixups and, worse, has
>>>> > led to crashes in the LZ4 decompressor code that does not have a trap
>>>> > handler.
>>>> >
>>>> > This adds an ARM specific version of asm/unaligned.h that uses the
>>>> > le_struct.h/be_struct.h implementation unconditionally. This should lead
>>>> > to essentially the same code on ARMv6+ as before, with the exception of
>>>> > using regular load/store instructions instead of the trapping instructions
>>>> > multi-register variants.
>>>> >
>>>> > The crash in the LZ4 decompressor code was probably introduced by the
>>>> > patch replacing the LZ4 implementation, commit 4e1a33b105dd ("lib: update
>>>> > LZ4 compressor module"), so linux-4.11 and higher would be affected most.
>>>> > However, we probably want to have this backported to all older stable
>>>> > kernels as well, to help with the performance issues.
>>>> >
>>>> > There are two follow-ups that I think we should also work on, but not
>>>> > backport to stable kernels, first to change the asm-generic version of
>>>> > the header to remove the ARM special case, and second to review all
>>>> > other uses of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see if they
>>>> > might be affected by the same problem on ARM.
>>>> >
>>>> > Cc: stable at vger.kernel.org
>>>> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>>>> > ---
>>>> > Untested so far, please verify that this fixes all the known problems
>>>> > with the alignment traps.
>>>>
>>>> I think Russell already find this conclusion but this patch didn't solve
>>>> my boot issue with dtb append.
>>>>
>>>> I tested this patch onto a v4.14-rc6.
>>>>
>>>> Then at least with the patch from Ard: "efi/libstub: arm: omit sorting
>>>> of the UEFI memory map", it didn't prevent booting.
>>>
>>> There's three things wrong, all of which I have patches to address:
>>>
>>> 1. The decompressor code reading the image data sometimes issues unaligned
>>> reads. Some compilers get this wrong and cause an abort. Arnds patch
>>> addresses this.
>>>
>>> 2. Additional sections can appear in the zImage binary which adds extra
>>> bytes on the end of the image. Concatenating the zImage with the
>>> extra bytes onto a DTB is the same thing as doing this:
>>>
>>> cat zImage extrabytes foo.dtb > image
>>>
>>> and the decompressor tolerates no additional bytes between the
>>> _official_ end of the zImage and the DTB. I've added a patch which
>>> detects this situation and fails the kernel build when it happens.
>>
>> So I tested the branch fixes in your git tree.
>>
>> After doing a "make multi_v7_defconfig; make zImage", I got the message
>> "arm-linux-gnueabi-ld: error: zImage file size is incorrect" you added
>> in the commit "ARM: verify size of zImage".
>>
>> It is the same with mvebu_v7_defconfig, so I wonder wich with
>> configuration this patch was tested ?
>>
>
> Could you please share the output of 'readelf -S' for those vmlinux
> decompressor images?
Here it is:
In the meantime I also used an arm-linux-gnueabihf- in case it could be
related to the toolchain, I had te same issue and here it is the readelf
output:
arm-linux-gnueabi-readelf -S ../build/vmlinux
There are 40 section headers, starting at offset 0x7cc06bc:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .head.text PROGBITS c0008000 008000 00026c 00 AX 0 0 4
[ 2] .text PROGBITS c0100000 010000 6bd280 00 AX 0 0 64
[ 3] .fixup PROGBITS c07bd280 6cd280 00001c 00 AX 0 0 4
[ 4] .rodata PROGBITS c0800000 6d0000 168321 00 WA 0 0 64
[ 5] .pci_fixup PROGBITS c0968324 838324 001e40 00 A 0 0 4
[ 6] __ksymtab PROGBITS c096a164 83a164 007c28 00 A 0 0 4
[ 7] __ksymtab_gpl PROGBITS c0971d8c 841d8c 0081c8 00 A 0 0 4
[ 8] __ksymtab_strings PROGBITS c0979f54 849f54 0266e6 00 A 0 0 1
[ 9] __param PROGBITS c09a063c 87063c 00102c 00 A 0 0 4
[10] __modver PROGBITS c09a1668 871668 000998 00 A 0 0 4
[11] __ex_table PROGBITS c09a2000 872000 000ef0 00 A 0 0 8
[12] .ARM.unwind_idx ARM_EXIDX c09a2ef0 872ef0 02f348 00 AL 17 0 4
[13] .ARM.unwind_tab PROGBITS c09d2238 8a2238 001458 00 A 0 0 4
[14] .notes NOTE c09d3690 8a3690 000024 00 A 0 0 4
[15] .vectors PROGBITS ffff0000 8b0000 000020 00 AX 0 0 4
[16] .stubs PROGBITS ffff1000 8b1000 0002ac 00 AX 0 0 32
[17] .init.text PROGBITS c0a002e0 8c02e0 04ee58 00 AX 0 0 32
[18] .exit.text PROGBITS c0a4f138 90f138 0018cc 00 AX 0 0 4
[19] .init.arch.info PROGBITS c0a50a04 910a04 000270 00 A 0 0 4
[20] .init.tagtable PROGBITS c0a50c74 910c74 000040 00 A 0 0 4
[21] .init.smpalt PROGBITS c0a50cb4 910cb4 00d070 00 A 0 0 4
[22] .init.pv_table PROGBITS c0a5dd24 91dd24 0001ec 00 A 0 0 1
[23] .init.data PROGBITS c0a5e000 91e000 011e7c 00 WA 0 0 4096
[24] .data..percpu PROGBITS c0a70000 930000 008f0c 00 WA 0 0 64
[25] .data PROGBITS c0b00000 940000 07f5e8 00 WA 0 0 64
[26] .bss NOBITS c0b7f600 9bf5e8 02be6c 00 WA 0 0 64
[27] .comment PROGBITS 00000000 9bf5e8 00001c 01 MS 0 0 1
[28] .ARM.attributes ARM_ATTRIBUTES 00000000 9bf604 000031 00 0 0 1
[29] .debug_line PROGBITS 00000000 9bf635 706427 00 0 0 1
[30] .debug_info PROGBITS 00000000 10c5a5c 5c11e67 00 0 0 1
[31] .debug_abbrev PROGBITS 00000000 6cd78c3 2efd55 00 0 0 1
[32] .debug_aranges PROGBITS 00000000 6fc7618 011340 00 0 0 8
[33] .debug_str PROGBITS 00000000 6fd8958 24bc04 01 MS 0 0 1
[34] .debug_ranges PROGBITS 00000000 7224560 1f2bd0 00 0 0 8
[35] .debug_frame PROGBITS 00000000 7417130 14fa24 00 0 0 4
[36] .debug_loc PROGBITS 00000000 7566b54 4562b5 00 0 0 1
[37] .symtab SYMTAB 00000000 79bce0c 1b8f60 10 38 95872 4
[38] .strtab STRTAB 00000000 7b75d6c 14a7a2 00 0 0 1
[39] .shstrtab STRTAB 00000000 7cc050e 0001ab 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
y (purecode), p (processor specific)
arm-linux-gnueabihf-readelf -S ../build/vmlinux
There are 40 section headers, starting at offset 0x7cc853c:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .head.text PROGBITS c0008000 008000 00026c 00 AX 0 0 4
[ 2] .text PROGBITS c0100000 010000 6bd860 00 AX 0 0 64
[ 3] .fixup PROGBITS c07bd860 6cd860 00001c 00 AX 0 0 4
[ 4] .rodata PROGBITS c0800000 6d0000 168361 00 WA 0 0 64
[ 5] .pci_fixup PROGBITS c0968364 838364 001e40 00 A 0 0 4
[ 6] __ksymtab PROGBITS c096a1a4 83a1a4 007c28 00 A 0 0 4
[ 7] __ksymtab_gpl PROGBITS c0971dcc 841dcc 0081c8 00 A 0 0 4
[ 8] __ksymtab_strings PROGBITS c0979f94 849f94 0266e6 00 A 0 0 1
[ 9] __param PROGBITS c09a067c 87067c 00102c 00 A 0 0 4
[10] __modver PROGBITS c09a16a8 8716a8 000958 00 A 0 0 4
[11] __ex_table PROGBITS c09a2000 872000 000ef0 00 A 0 0 8
[12] .ARM.unwind_idx ARM_EXIDX c09a2ef0 872ef0 02f368 00 AL 17 0 4
[13] .ARM.unwind_tab PROGBITS c09d2258 8a2258 001458 00 A 0 0 4
[14] .notes NOTE c09d36b0 8a36b0 000024 00 A 0 0 4
[15] .vectors PROGBITS ffff0000 8b0000 000020 00 AX 0 0 4
[16] .stubs PROGBITS ffff1000 8b1000 0002ac 00 AX 0 0 32
[17] .init.text PROGBITS c0a002e0 8c02e0 04ee58 00 AX 0 0 32
[18] .exit.text PROGBITS c0a4f138 90f138 0018cc 00 AX 0 0 4
[19] .init.arch.info PROGBITS c0a50a04 910a04 000270 00 A 0 0 4
[20] .init.tagtable PROGBITS c0a50c74 910c74 000040 00 A 0 0 4
[21] .init.smpalt PROGBITS c0a50cb4 910cb4 00d070 00 A 0 0 4
[22] .init.pv_table PROGBITS c0a5dd24 91dd24 0001ec 00 A 0 0 1
[23] .init.data PROGBITS c0a5e000 91e000 011e7c 00 WA 0 0 4096
[24] .data..percpu PROGBITS c0a70000 930000 008f0c 00 WA 0 0 64
[25] .data PROGBITS c0b00000 940000 07f5e8 00 WA 0 0 64
[26] .bss NOBITS c0b7f600 9bf5e8 02be6c 00 WA 0 0 64
[27] .comment PROGBITS 00000000 9bf5e8 00001c 01 MS 0 0 1
[28] .ARM.attributes ARM_ATTRIBUTES 00000000 9bf604 000031 00 0 0 1
[29] .debug_line PROGBITS 00000000 9bf635 70533b 00 0 0 1
[30] .debug_info PROGBITS 00000000 10c4970 5c18a6b 00 0 0 1
[31] .debug_abbrev PROGBITS 00000000 6cdd3db 2eff72 00 0 0 1
[32] .debug_aranges PROGBITS 00000000 6fcd350 011340 00 0 0 8
[33] .debug_str PROGBITS 00000000 6fde690 24bc92 01 MS 0 0 1
[34] .debug_ranges PROGBITS 00000000 722a328 1f41c8 00 0 0 8
[35] .debug_frame PROGBITS 00000000 741e4f0 14fa78 00 0 0 4
[36] .debug_loc PROGBITS 00000000 756df68 456ca3 00 0 0 1
[37] .symtab SYMTAB 00000000 79c4c0c 1b8f90 10 38 95875 4
[38] .strtab STRTAB 00000000 7b7db9c 14a7f5 00 0 0 1
[39] .shstrtab STRTAB 00000000 7cc8391 0001ab 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
y (purecode), p (processor specific)
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
More information about the linux-arm-kernel
mailing list