From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751867AbdCACDl (ORCPT ); Tue, 28 Feb 2017 21:03:41 -0500 Received: from mail-io0-f194.google.com ([209.85.223.194]:33278 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751439AbdCACDd (ORCPT ); Tue, 28 Feb 2017 21:03:33 -0500 MIME-Version: 1.0 In-Reply-To: <20170228075305.GA8775@gmail.com> References: <20170228075305.GA8775@gmail.com> From: Linus Torvalds Date: Tue, 28 Feb 2017 17:55:11 -0800 X-Google-Sender-Auth: 0XJfT6Y3O4-H6Q1I7NJAJCCgIMM Message-ID: Subject: Re: [GIT PULL] objtool fixes To: Ingo Molnar , Josh Poimboeuf Cc: Linux Kernel Mailing List , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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... Linus