[PATCH] ARM: add a private asm/unaligned.h

[Ard Biesheuvel]

On 31 October 2017 at 12:47, Russell King - ARM Linux
<linux at armlinux.org.uk> wrote:
> On Mon, Oct 30, 2017 at 04:38:17PM +0000, Russell King - ARM Linux wrote:
>> On Mon, Oct 30, 2017 at 05:24:34PM +0100, Gregory CLEMENT wrote:
>> > Hi Russell King,
>> >
>> > Here you will find all the objects included the vmlinux:
>> >
>> > http://free-electrons.com/~gregory/pub/compressed.tgz
>>
>> Thanks.  Unfortunately, nothing stands out, but I do see a difference
>> between the output of your linker from mine.
>>
>> Yours:
>>
>> Idx Name          Size      VMA       LMA       File off  Algn
>>   0 .text         00005ef8  00000000  00000000  00010000  2**5
>>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>>
>> Mine:
>>
>> Idx Name          Size      VMA       LMA       File off  Algn
>>   0 .text         00005f00  00000000  00000000  00010000  2**5
>>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>>
>> That has the effect of moving the addresses of the following
>> sections in your vmlinux down by 8 bytes.  However, I don't think
>> that's the cause of this - but it does hint at something being
>> different in binutils in the way sections are processed in the
>> linker.
>>
>> Please add to your linker script after the assignment of _edata:
>>
>>   .image_end (NOLOAD) : {
>>     _edata_foo = .;
>>   }
>>
>> relink the decompressor, and see what value _edata_foo ends up with
>> compared to _edata?  They should be the same, but I suspect using
>> your linker, they will be different.
>>
>> Also try adding
>>     BYTE(0);
>>
>> after the _edata_foo assignment as a separate test, and see whether
>> that makes any difference - with that you should end up with the
>> .image_end section in the output image.
>
> Gregory sent me has new url... for _both_ changes, which gives me:
>
> $ arm-linux-nm vmlinux |grep _edata
> 00491160 D _edata
> 00491160 D _edata_foo
>
> So there's no reason that ASSERT() should be failing!  However, as I
> don't have the intermediate step, I can't say whether the addition
> of the BYTE() affected it in some way - sorry, but I asked for _both_
> to be tested above because I wanted to speed up the process, and
> clearly that's backfired.
>
> Given how close we potentially are to 4.14, I don't think we're going
> to get to the bottom of this to make 4.14.  I'd want to get this
> sorted by Wednesday so linux-next (which is resuming this evening)
> can grab a copy of my tree with it in, and we have another day to
> sort out any remaining issues, but I'm basically out of time to do
> anything further with this as of now.
>
> So, 4.14 will likely be released without any of this being fixed.
>

IIUC, the current issue is limited to the ASSERT() itself, which is
there to prevent future regressions, while the other two patches deal
with severe and difficult to diagnose known issues.

So why can't we apply those two patches as fixes, and revisit the
patch that helps us prevent this from regressing in the future for
v4.15?