On Wed, Mar 01, 2017 at 01:44:01PM +0100, Ingo Molnar wrote:
>
> * Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
>
> > On Wed, Mar 01, 2017 at 12:15:38AM -0800, hpa@xxxxxxxxx wrote:
> > > On March 1, 2017 12:10:59 AM PST, tip-bot for Josh Poimboeuf <tipbot@xxxxxxxxx> wrote:
> > > >Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5
> > > >Gitweb:
> > > >http://git.kernel.org/tip/90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5
> > > >Author: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> > > >AuthorDate: Wed, 1 Mar 2017 00:05:04 -0600
> > > >Committer: Ingo Molnar <mingo@xxxxxxxxxx>
> > > >CommitDate: Wed, 1 Mar 2017 07:38:25 +0100
> > > >
> > > >objtool: Fix __unreachable section relocation size
> > > >
> > > >Linus reported the following commit broke module loading on his laptop:
> > > >
> > > >d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead
> > > >ends")
> > > >
> > > >It showed errors like the following:
> > > >
> > > > module: overflow in relocation type 10 val ffffffffc02afc81
> > > > module: 'nvme' likely not compiled with -mcmodel=kernel
> > > >
> > > >The problem is that the __unreachable section addresses are stored
> > > >using
> > > >the '.long' asm directive, which isn't big enough for .text section
> > > >relative kernel addresses. Use '.quad' instead.
> > > >
> > > >Suggested-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> > > >Reported-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> > > >Signed-off-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> > > >Cc: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> > > >Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > > >Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> > > >Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other
> > > >dead ends")
> > > >Link: http://lkml.kernel.org/r/20170301060504.oltm3iws6fmubnom@treble
> > > >Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>
> > > >---
> > > > include/linux/compiler-gcc.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > >diff --git a/include/linux/compiler-gcc.h
> > > >b/include/linux/compiler-gcc.h
> > > >index 76e28c2..91a77a5 100644
> > > >--- a/include/linux/compiler-gcc.h
> > > >+++ b/include/linux/compiler-gcc.h
> > > >@@ -201,7 +201,7 @@
> > > > #define annotate_unreachable() ({ \
> > > > asm("%c0:\t\n" \
> > > > ".pushsection __unreachable, \"a\"\t\n" \
> > > >- ".long %c0b\t\n" \
> > > >+ ".quad %c0b\t\n" \
> > > > ".popsection\t\n" : : "i" (__LINE__)); \
> > > > })
> > > > #else
> > >
> > > Or perhaps better use relative addresses, so:
> > >
> > > .long foo - (.+4)
> >
> > Hm, yeah, something like that would indeed be better as it only needs 4
> > bytes instead of 8. For this use case, the following seems to work:
> >
> > ".long %c0b - .\t\n"
> >
> > It produces the same relocation section+addend as before but with a
> > X86_64_PC32 relocation.
> >
> > It looks like the above patch was already merged so I'll add that change
> > to the TODO list unless Ingo can squash it with the above patch.
>
> I've squashed it - attached the latest version. Does this look good to everyone?
>
> Thanks,
>
> Ingo
>
> ================>
> From a6ae17f553bf9b4a0c7f8534e5f0f983bc7955c7 Mon Sep 17 00:00:00 2001
> From: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> Date: Wed, 1 Mar 2017 00:05:04 -0600
> Subject: [PATCH] objtool, compiler.h: Fix __unreachable section relocation size
>
> Linus reported the following commit broke module loading on his laptop:
>
> d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends")
>
> It showed errors like the following:
>
> module: overflow in relocation type 10 val ffffffffc02afc81
> module: 'nvme' likely not compiled with -mcmodel=kernel
>
> The problem is that the __unreachable section addresses are stored using
> the '.long' asm directive, which isn't big enough for .text section
> relative kernel addresses. Use relative addresses instead:
Maybe remove the first "relative" in the last line. Otherwise it looks
good to me. Thanks Ingo!
--
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|