From: Gregory CLEMENT <gregory.clement@free-electrons.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
Arnd Bergmann <arnd@arndb.de>,
Aaro Koskinen <aaro.koskinen@iki.fi>,
Petr Cvek <petrcvekcz@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrea Adami <andrea.adami@gmail.com>,
Romain Izard <romain.izard.pro@gmail.com>,
Sven Schmidt <4sschmid@informatik.uni-hamburg.de>,
Robert Jarzmik <robert.jarzmik@free.fr>,
"linux-arm-kernel\@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: add a private asm/unaligned.h
Date: Tue, 31 Oct 2017 14:22:38 +0100 [thread overview]
Message-ID: <87mv478na9.fsf@free-electrons.com> (raw)
In-Reply-To: <CAKv+Gu-te-Q+em36jM-dyouZuov_=xJaVY0Yr-3JCmJn6Zi4sg@mail.gmail.com> (Ard Biesheuvel's message of "Tue, 31 Oct 2017 12:57:35 +0000")
Hi Ard,
On mar., oct. 31 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 31 October 2017 at 12:47, Russell King - ARM Linux
> <linux@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:
If needed I can provide this url.
>>
>> $ 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.
I confirm that whithout the last commit (adding the ASSERT()) in the
fixes branch it worked well.
>
> 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?
I also agree with this.
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2017-10-31 13:22 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 20:01 [PATCH] ARM: add a private asm/unaligned.h Arnd Bergmann
2017-10-20 20:22 ` Ard Biesheuvel
2017-10-23 15:04 ` Romain Izard
2017-10-27 15:19 ` Gregory CLEMENT
2017-10-27 15:27 ` Russell King - ARM Linux
2017-10-30 13:48 ` Gregory CLEMENT
2017-10-30 14:55 ` Ard Biesheuvel
2017-10-30 15:05 ` Gregory CLEMENT
2017-10-30 15:07 ` Ard Biesheuvel
2017-10-30 15:09 ` Gregory CLEMENT
2017-10-30 15:20 ` Ard Biesheuvel
2017-10-30 15:33 ` Gregory CLEMENT
2017-10-30 15:35 ` Ard Biesheuvel
2017-10-30 15:40 ` Gregory CLEMENT
2017-10-30 16:59 ` Russell King - ARM Linux
2017-10-30 15:55 ` Russell King - ARM Linux
2017-10-30 16:04 ` Gregory CLEMENT
2017-10-30 15:48 ` Russell King - ARM Linux
2017-10-30 16:01 ` Gregory CLEMENT
2017-10-30 16:12 ` Russell King - ARM Linux
2017-10-30 16:24 ` Gregory CLEMENT
2017-10-30 16:38 ` Russell King - ARM Linux
2017-10-31 12:47 ` Russell King - ARM Linux
2017-10-31 12:57 ` Ard Biesheuvel
2017-10-31 13:22 ` Gregory CLEMENT [this message]
2017-11-01 15:57 ` Ard Biesheuvel
2017-11-01 18:00 ` Russell King - ARM Linux
2017-11-01 18:02 ` Ard Biesheuvel
2017-11-01 18:11 ` Russell King - ARM Linux
2017-11-01 18:20 ` Ard Biesheuvel
2017-11-01 19:10 ` Russell King - ARM Linux
2017-10-30 15:09 ` Arnd Bergmann
2017-10-30 15:50 ` Russell King - ARM Linux
2017-10-30 17:01 ` Arnd Bergmann
2017-10-30 17:13 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mv478na9.fsf@free-electrons.com \
--to=gregory.clement@free-electrons.com \
--cc=4sschmid@informatik.uni-hamburg.de \
--cc=aaro.koskinen@iki.fi \
--cc=andrea.adami@gmail.com \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=petrcvekcz@gmail.com \
--cc=robert.jarzmik@free.fr \
--cc=romain.izard.pro@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).