linux-kernel - Re: linux-next: build failure after merge of the powerpc tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 23 Nov 2016 13:02:10 +1100
From:   Nicholas Piggin <npiggin@...il.com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        PowerPC <linuxppc-dev@...ts.ozlabs.org>,
        linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the powerpc tree

On Tue, 22 Nov 2016 21:21:14 +1100
Stephen Rothwell <sfr@...b.auug.org.au> wrote:

> Hi all,
> 
> On Tue, 22 Nov 2016 19:58:32 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >
> > After merging the powerpc tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> > 
> > Inconsistent kallsyms data
> > Try make KALLSYMS_EXTRA_PASS=1 as a workaround
> > 
> > Which is a vast improvement.  I'll try adding 'KALLSYMS_EXTRA_PASS=1'
> > later and see how it goes.  It would be nice not to need it, though.  
> 
> It build with KALLSYMS_EXTRA_PASS=1 on the command line.
> 

Yay!

The inconsistent kallsyms data is not something we're doing wrong or
toolchain bug so much as an inherent flaw in how kallsyms are done.
Basically the allyesconfig kallsyms section expands the kernel so much
that a subsequent linking requires even more stubs, which adds more
symbols, which means the next kallsyms will be a different size, which
means or offsets will be wrong :)

In theory I think it could actually be triggered on smaller kernels if
the size was just right. I'm sort of looking at ways to fix it:

https://patchwork.ozlabs.org/patch/684910/

Hopefully will get something in 4.10. Worst case we could detect the
kallsyms size change and do another pass in response without slowing
down the case where it's not required. Hmm, that might be the best
thing to do for a first pass.

Thanks,
Nick