linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [GIT PULL] objtool fixes
Date: Wed, 1 Mar 2017 00:05:04 -0600	[thread overview]
Message-ID: <20170301060504.oltm3iws6fmubnom@treble> (raw)
In-Reply-To: <CA+55aFw3+uoT=9Rh0LCF5fhCRtY0uaRHTs+6_K5pSjqrvZdMRw@mail.gmail.com>

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 <mingo@kernel.org> 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 <nvme_admin_init_request>:
>         ....
>      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 <jpoimboe@redhat.com>
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 <torvalds@linux-foundation.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends")
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 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 f457b520..7bd21e8 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -199,7 +199,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

  reply	other threads:[~2017-03-01  6:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28  7:53 [GIT PULL] objtool fixes Ingo Molnar
2017-03-01  1:55 ` Linus Torvalds
2017-03-01  6:05   ` Josh Poimboeuf [this message]
2017-03-01  8:10     ` [tip:core/urgent] objtool: Fix __unreachable section relocation size tip-bot for Josh Poimboeuf
2017-03-01  8:15       ` hpa
2017-03-01 12:41         ` Josh Poimboeuf
2017-03-01 12:44           ` [PATCH] objtool, compiler.h: " Ingo Molnar
2017-03-01 12:56             ` Josh Poimboeuf
2017-03-01 10:37       ` [tip:core/urgent] objtool: " Ingo Molnar
2017-03-01 12:43         ` Josh Poimboeuf
2017-03-01 12:45     ` [tip:core/urgent] objtool, compiler.h: " tip-bot for Josh Poimboeuf
2017-03-01 13:24     ` tip-bot for Josh Poimboeuf
  -- strict thread matches above, loose matches on Subject: below --
2021-06-24  6:54 [GIT PULL] objtool fixes Ingo Molnar
2021-06-24 16:34 ` pr-tracker-bot
2021-06-12 12:37 Ingo Molnar
2021-06-12 19:09 ` pr-tracker-bot
2021-05-15  7:46 Ingo Molnar
2021-05-15 17:55 ` pr-tracker-bot
2020-04-25  9:04 Ingo Molnar
2020-04-25 19:30 ` pr-tracker-bot
2018-11-30  6:18 Ingo Molnar
2018-11-30 21:00 ` pr-tracker-bot
2017-11-26 12:34 Ingo Molnar
2017-03-01 22:01 Ingo Molnar
2016-04-23 11:10 Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170301060504.oltm3iws6fmubnom@treble \
    --to=jpoimboe@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).