linux-next: build failure after merge of the final tree

linux-next: build failure after merge of the final tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

Hi all,

After merging the final tree, today's linux-next build (i386 defconfig)
failed like this:

Invalid absolute R_386_32 relocation: jiffies

I am not sure what caused this (it may even been a bad merge on my
part).  I have left it broken for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the final tree, today's linux-next build (i386 defconfig)
> failed like this:
> 
> Invalid absolute R_386_32 relocation: jiffies

Hm, that's our fault: seems like a linker bug fallout, one which 
we fixed in -tip.

> I am not sure what caused this (it may even been a bad merge 
> on my part).  I have left it broken for today.

While we've fixed this, to simplify merge window integration of 
linux-next I've excluded tip:x86/trampoline from the linux-next 
branch for now, so this build failure should go away tomorrow.

Sorry and thanks,

	Ingo

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

Hi Ingo,

On Mon, 21 May 2012 11:12:57 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > After merging the final tree, today's linux-next build (i386 defconfig)
> > failed like this:
> > 
> > Invalid absolute R_386_32 relocation: jiffies
> 
> Hm, that's our fault: seems like a linker bug fallout, one which 
> we fixed in -tip.
> 
> > I am not sure what caused this (it may even been a bad merge 
> > on my part).  I have left it broken for today.
> 
> While we've fixed this, to simplify merge window integration of 
> linux-next I've excluded tip:x86/trampoline from the linux-next 
> branch for now, so this build failure should go away tomorrow.

OK, thanks
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

Hi Ingo,

On Mon, 21 May 2012 11:12:57 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > After merging the final tree, today's linux-next build (i386 defconfig)
> > failed like this:
> > 
> > Invalid absolute R_386_32 relocation: jiffies
> 
> Hm, that's our fault: seems like a linker bug fallout, one which 
> we fixed in -tip.
> 
> > I am not sure what caused this (it may even been a bad merge 
> > on my part).  I have left it broken for today.
> 
> While we've fixed this, to simplify merge window integration of 
> linux-next I've excluded tip:x86/trampoline from the linux-next 
> branch for now, so this build failure should go away tomorrow.

Weirdly, I still got the same error today.  Any ideas?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Mon, 21 May 2012 11:12:57 +0200 Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > Hi all,
> > > 
> > > After merging the final tree, today's linux-next build (i386 defconfig)
> > > failed like this:
> > > 
> > > Invalid absolute R_386_32 relocation: jiffies
> > 
> > Hm, that's our fault: seems like a linker bug fallout, one which 
> > we fixed in -tip.
> > 
> > > I am not sure what caused this (it may even been a bad merge 
> > > on my part).  I have left it broken for today.
> > 
> > While we've fixed this, to simplify merge window integration of 
> > linux-next I've excluded tip:x86/trampoline from the linux-next 
> > branch for now, so this build failure should go away tomorrow.
> 
> Weirdly, I still got the same error today.  Any ideas?

Ought to be fixed now.

Thanks,

	Ingo

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]

Hi Ingo,

On Wed, 23 May 2012 17:35:36 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > On Mon, 21 May 2012 11:12:57 +0200 Ingo Molnar <mingo@kernel.org> wrote:
> > >
> > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > > After merging the final tree, today's linux-next build (i386 defconfig)
> > > > failed like this:
> > > > 
> > > > Invalid absolute R_386_32 relocation: jiffies
> > > 
> > > Hm, that's our fault: seems like a linker bug fallout, one which 
> > > we fixed in -tip.
> > > 
> > > > I am not sure what caused this (it may even been a bad merge 
> > > > on my part).  I have left it broken for today.
> > > 
> > > While we've fixed this, to simplify merge window integration of 
> > > linux-next I've excluded tip:x86/trampoline from the linux-next 
> > > branch for now, so this build failure should go away tomorrow.
> > 
> > Weirdly, I still got the same error today.  Any ideas?
> 
> Ought to be fixed now.

OK, clearly something is wrong :-( There could well be a problem with my
toolchain.

I am still getting this error.  Build is an i386 defconfig

$ i386-linux-gcc --version
i386-linux-gcc (GCC) 4.6.0
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ i386-linux-ld --version
GNU ld (GNU Binutils) 2.21
Copyright 2010 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

I have CONFIG_DEBUG_SECTION_MISMATCH=y and -s on the build command line.

This is the entire build log:

In file included from /scratch/sfr/next/arch/x86/include/asm/uaccess.h:580:0,
                 from /scratch/sfr/next/include/linux/uaccess.h:5,
                 from /scratch/sfr/next/include/linux/highmem.h:8,
                 from /scratch/sfr/next/include/linux/pagemap.h:10,
                 from /scratch/sfr/next/fs/binfmt_misc.c:27:
/scratch/sfr/next/arch/x86/include/asm/uaccess_32.h: In function 'parse_command.part.1':
/scratch/sfr/next/arch/x86/include/asm/uaccess_32.h:211:26: warning: call to 'copy_from_user_overflow' declared with attribute warning: copy_from_user() buffer size is not provably correct [enabled by default]
sort done marker at 9112a4
Invalid absolute R_386_32 relocation: jiffies
make[3]: *** [arch/x86/boot/compressed/vmlinux.relocs] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [arch/x86/boot/compressed/vmlinux] Error 2
make[1]: *** [bzImage] Error 2
make: *** [sub-make] Error 2

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Wed, 23 May 2012 17:35:36 +0200 Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > On Mon, 21 May 2012 11:12:57 +0200 Ingo Molnar <mingo@kernel.org> wrote:
> > > >
> > > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > 
> > > > > After merging the final tree, today's linux-next build (i386 defconfig)
> > > > > failed like this:
> > > > > 
> > > > > Invalid absolute R_386_32 relocation: jiffies
> > > > 
> > > > Hm, that's our fault: seems like a linker bug fallout, one which 
> > > > we fixed in -tip.
> > > > 
> > > > > I am not sure what caused this (it may even been a bad merge 
> > > > > on my part).  I have left it broken for today.
> > > > 
> > > > While we've fixed this, to simplify merge window integration of 
> > > > linux-next I've excluded tip:x86/trampoline from the linux-next 
> > > > branch for now, so this build failure should go away tomorrow.
> > > 
> > > Weirdly, I still got the same error today.  Any ideas?
> > 
> > Ought to be fixed now.
> 
> OK, clearly something is wrong :-( There could well be a 
> problem with my toolchain.
> 
> I am still getting this error.  Build is an i386 defconfig

Hm, Peter?

Thanks,

	Ingo

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

[H. Peter Anvin]

[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]

On 05/24/2012 12:16 AM, Stephen Rothwell wrote:
> 
> OK, clearly something is wrong :-( There could well be a problem with my
> toolchain.
> 

Apparently so... this is troublesome because it means that we have
silently built broken kernels not just with ld 2.22.52.0.x but with
older lds as well.

What originally made the ld problems surface was actually checking that
we didn't run into any absolute symbols we didn't know about, which
previously was supposed to be done by developers manually, i.e. never
done.  This is extremely serious because it means that a kernel compiled
with CONFIG_RELOCATABLE doesn't actually relocate.

The workaround -- and it is a workaround -- is to take these symbols as
they appear and add them to the [S_REL] whitelist in
arch/x86/tools/relocs.c.  This is the same workaround as existed before,
the only difference is that we are now enforcing it.

A patch for this particular subcase is attached and I will commit it to
tip:x86/urgent.

> $ i386-linux-ld --version
> GNU ld (GNU Binutils) 2.21
> Copyright 2010 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.

> Invalid absolute R_386_32 relocation: jiffies
> make[3]: *** [arch/x86/boot/compressed/vmlinux.relocs] Error 1
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [arch/x86/boot/compressed/vmlinux] Error 2
> make[1]: *** [bzImage] Error 2
> make: *** [sub-make] Error 2

jiffies is yet another symbol created by the linker script.  This one in
particular is created outside any section, so it isn't all that strange
that some versions of the linker created it absolute.  Again, such a
kernel would have malfunctioned if relocated.

The really disturbing part of this one is that it shows that these
problems covers multiple GNU ld versions.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


[-- Attachment #2: 0001-x86-relocs-Add-jiffies-and-jiffies_64-to-the-relativ.patch --]
[-- Type: text/x-patch, Size: 1371 bytes --]

>From a8040166e638e3d5d982e339e20d1569641ce404 Mon Sep 17 00:00:00 2001
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Thu, 24 May 2012 07:01:38 -0700
Subject: [PATCH] x86, relocs: Add jiffies and jiffies_64 to the relative
 whitelist

The symbol jiffies is created in the linker script as an alias to
jiffies_64.  Unfortunately this is done outside any section, and
apparently GNU ld 2.21 doesn't carry the section with it, so we end up
with an absolute symbol and therefore a broken kernel.

Add jiffies and jiffies_64 to the whitelist.

The most disturbing bit with this discovery is that it shows that we
have had multiple linker bugs in this area crossing multiple
generations, and have been silently building bad kernels for some time.

Link: http://lkml.kernel.org/r/20120524171604.0d98284f3affc643e9714470@canb.auug.org.au
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
---
 arch/x86/tools/relocs.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index b8f7c65..b685296 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -71,6 +71,7 @@ static const char * const sym_regex_kernel[S_NSYMTYPES] = {
 	"__(start|stop)_notes|"
 	"__end_rodata|"
 	"__initramfs_start|"
+	"(jiffies|jiffies_64)|"
 	"_end)$"
 };
 
-- 
1.7.6.5

[tip:x86/urgent] x86, relocs: Add jiffies and jiffies_64 to the relative whitelist

[tip-bot for H. Peter Anvin]

Commit-ID:  ea17e7414bc62e8d3bde8d08e3df1d921c518c17
Gitweb:     http://git.kernel.org/tip/ea17e7414bc62e8d3bde8d08e3df1d921c518c17
Author:     H. Peter Anvin <hpa@zytor.com>
AuthorDate: Thu, 24 May 2012 07:01:38 -0700
Committer:  H. Peter Anvin <hpa@zytor.com>
CommitDate: Thu, 24 May 2012 07:16:18 -0700

x86, relocs: Add jiffies and jiffies_64 to the relative whitelist

The symbol jiffies is created in the linker script as an alias to
jiffies_64.  Unfortunately this is done outside any section, and
apparently GNU ld 2.21 doesn't carry the section with it, so we end up
with an absolute symbol and therefore a broken kernel.

Add jiffies and jiffies_64 to the whitelist.

The most disturbing bit with this discovery is that it shows that we
have had multiple linker bugs in this area crossing multiple
generations, and have been silently building bad kernels for some time.

Link: http://lkml.kernel.org/r/20120524171604.0d98284f3affc643e9714470@canb.auug.org.au
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: <stable@vger.kernel.org> v3.4
---
 arch/x86/tools/relocs.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index b8f7c65..b685296 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -71,6 +71,7 @@ static const char * const sym_regex_kernel[S_NSYMTYPES] = {
 	"__(start|stop)_notes|"
 	"__end_rodata|"
 	"__initramfs_start|"
+	"(jiffies|jiffies_64)|"
 	"_end)$"
 };