From e582bbd7279dcc29b7458459592db49095b931c3 Mon Sep 17 00:00:00 2001 From: Laura Abbott Date: Wed, 1 Mar 2017 12:56:12 -0800 Subject: [PATCH] Fix for objtool/module breakage --- kernel.spec | 3 + objtool-fix.patch | 153 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 156 insertions(+) create mode 100644 objtool-fix.patch diff --git a/kernel.spec b/kernel.spec index 73f2a3204..08b1b2cca 100644 --- a/kernel.spec +++ b/kernel.spec @@ -602,6 +602,9 @@ Patch666: ccm-stack.patch # grabbed from mailing list Patch667: v3-Revert-tty-serial-pl011-add-ttyAMA-for-matching-pl011-console.patch +# reported via IRC +Patch668: objtool-fix.patch + # END OF PATCH DEFINITIONS %endif diff --git a/objtool-fix.patch b/objtool-fix.patch new file mode 100644 index 000000000..fcf0c9956 --- /dev/null +++ b/objtool-fix.patch @@ -0,0 +1,153 @@ +From 898d20ca04d5a13dcca5483ed5213ad92fed88d3 Mon Sep 17 00:00:00 2001 +From: Josh Poimboeuf +Date: Wed, 1 Mar 2017 00:05:04 -0600 +Subject: [PATCH] objtool fixes + +On Tue, Feb 28, 2017 at 05:55:11PM -0800, Linus Torvalds wrote: +> Guys, +> the recent 'objtool' pull request broke things. +> +> I haven't bisected it, but I'm pretty sure that this part is pure garbage: +> +> On Mon, Feb 27, 2017 at 11:53 PM, Ingo Molnar wrote: +> > +> > diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S +> > index e79f15f108a8..ad0118fbce90 100644 +> > --- a/arch/x86/kernel/vmlinux.lds.S +> > +++ b/arch/x86/kernel/vmlinux.lds.S +> > @@ -346,6 +346,7 @@ SECTIONS +> > /DISCARD/ : { +> > *(.eh_frame) +> > *(__func_stack_frame_non_standard) +> > + *(__unreachable) +> > } +> > } +> > +> > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h +> > index 0444b1336268..f457b520ead6 100644 +> > --- a/include/linux/compiler-gcc.h +> > +++ b/include/linux/compiler-gcc.h +> > @@ -195,6 +195,17 @@ +> > #endif +> > #endif +> > +> > +#ifdef CONFIG_STACK_VALIDATION +> > +#define annotate_unreachable() ({ \ +> > + asm("%c0:\t\n" \ +> > + ".pushsection __unreachable, \"a\"\t\n" \ +> > + ".long %c0b\t\n" \ +> > + ".popsection\t\n" : : "i" (__LINE__)); \ +> > +}) +> > +#else +> > +#define annotate_unreachable() +> > +#endif +> +> and I think the above is what breaks module loading for me right now +> on my laptop. +> +> I get this during bootup: +> +> module: overflow in relocation type 10 val ffffffffc02afc81 +> module: 'nvme' likely not compiled with -mcmodel=kernel +> +> (and similar errors for other modules too), but those modules very +> much *are* compiled with all the normal kernel build flags, including +> -mcmodel=kernel. +> +> Now, relocation type 10 is R_X86_64_32, so the warning is very true: +> that address would fit in a _signed_ 32-bit value, but that's +> supposedly a 32-bit unsigned relocation. +> +> Trying to figure out what the hell is going on, I do: +> +> objdump -r nvme.ko | grep 64_32 +> +> and what do I find? I find +> +> RELOCATION RECORDS FOR [__unreachable]: +> OFFSET TYPE VALUE +> 0000000000000000 R_X86_64_32 .text+0x0000000000000c81 +> 0000000000000004 R_X86_64_32 .text+0x0000000000000cb5 +> 0000000000000008 R_X86_64_32 .text+0x0000000000001a18 +> 000000000000000c R_X86_64_32 .text+0x0000000000001a36 +> 0000000000000010 R_X86_64_32 .text+0x0000000000001e38 +> 0000000000000014 R_X86_64_32 .text+0x0000000000001ec2 +> 0000000000000018 R_X86_64_32 .text+0x00000000000034e2 +> 000000000000001c R_X86_64_32 .text+0x0000000000003536 +> +> and then when I look more closely (objdump --disassemble), I see that +> the offset 000c81 in the module refers to this: +> +> 0000000000000c60 : +> .... +> c7f: 0f 0b ud2 +> c81: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) +> +> so it very much looks like those relocations are still around on +> modules, and so module loading fails. +> +> Anyway, those annotations are completely bogus anyway, it looks. You +> guys should use relative offsets in order to be able to specify a +> kernel address. So doing +> +> .long %c0 +> +> is garbage - either it needs to be a .quad, or it needs to be relative +> to the text section to fit in a .long. +> +> Hmm? Revert or fix, but please quickly... + +Yuck, sorry about that. Patch to fix it below. + +This also highlights another (minor) issue: the '__unreachable' section +is meant to be a compile-time-only thing. It's supposed to be discarded +at link time, but apparently that isn't happening for modules. + +I tried excluding it from linking with the .pushsection "e" flag, but no +luck. I'll try to figure out how to fix that shortly. + +In the meantime, here's the fix you need. It now uses X86_64_64 +relocations. + +---- + +From: Josh Poimboeuf +Subject: [PATCH] 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. + +Reported-by: Linus Torvalds +Suggested-by: Linus Torvalds +Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends") +Signed-off-by: Josh Poimboeuf +--- + 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 +-- +2.7.4 +