All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Borislav Petkov <bp@suse.de>, Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>
Cc: x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org>,
	KVM list <kvm@vger.kernel.org>
Subject: Re: [GIT PULL] objtool/urgent for v5.15-rc4
Date: Sun, 3 Oct 2021 12:02:49 -0700	[thread overview]
Message-ID: <CAHk-=wiZwq-0LknKhXN4M+T8jbxn_2i9mcKpO+OaBSSq_Eh7tg@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wh9JzLmwAqA2+cA=Y4x_TYNBZv_OM4eSEDFPF8V_GAPug@mail.gmail.com>

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

On Sun, Oct 3, 2021 at 11:38 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Looking at the kvm code, that kvm_fastop_exception thing is some funky sh*t.
>
> I _think_ the problem is that 'kvm_fastop_exception' is done with bare
> asm at the top-level and that triggers some odd interaction with other
> section data, but I really don't know.

No, it's the fact that it is marked as a global function (why?) that
it then causes problems.

Now, I don't actually see why it would cause problems (the same way I
don't see why it's marked global). But removing that

     ".global kvm_fastop_exception \n"

works.

I suspect it makes the linker do the relocation for us before objtool
runs, because now that it's a local name, there is no worry about
multiply defined symbols of the same name or anything like that.

I also suspect that the reason for the warning is that the symbol type
has never been declared, so it's not marked as a STT_FUNC in the
relocation information.

So independently of this kvm_fastop_exception issue, I'd suggest the
attached patch for objtool to make the warning more informative for
people who try to debug this.

So I have a fix ("remove the global declaration"), but I really don't
like how random this is.

I also tried to instead keep the symbol global, and just mark
kvm_fastop_exception as a function (and add the proper size
annotation), but that only causes more objtool warnings for the
(generated asm) functions that *use* that symbol. Because they also
don't seem to be properly annotated.

Again, removing the global annotation works around the problem, but
the real underlying issue does seem to be that "funky sh*t" going on
in arch/x86/kvm/emulate.c.

So I'd like more people to look at this.

In the meantime, I think the exception handling for kvm
divide/multiply emulation is badly broken right now. Hmm?

                Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 1211 bytes --]

 tools/objtool/special.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/objtool/special.c b/tools/objtool/special.c
index f58ecc50fb10..f1428e32a505 100644
--- a/tools/objtool/special.c
+++ b/tools/objtool/special.c
@@ -110,8 +110,10 @@ static int get_alt_entry(struct elf *elf, struct special_entry *entry,
 		return -1;
 	}
 	if (!reloc2sec_off(orig_reloc, &alt->orig_sec, &alt->orig_off)) {
-		WARN_FUNC("don't know how to handle reloc symbol type: %s",
-			   sec, offset + entry->orig, orig_reloc->sym->name);
+		WARN_FUNC("don't know how to handle reloc symbol type %d: %s",
+			   sec, offset + entry->orig,
+			   orig_reloc->sym->type,
+			   orig_reloc->sym->name);
 		return -1;
 	}
 
@@ -132,8 +134,10 @@ static int get_alt_entry(struct elf *elf, struct special_entry *entry,
 			return 1;
 
 		if (!reloc2sec_off(new_reloc, &alt->new_sec, &alt->new_off)) {
-			WARN_FUNC("don't know how to handle reloc symbol type: %s",
-				  sec, offset + entry->new, new_reloc->sym->name);
+			WARN_FUNC("don't know how to handle reloc symbol type %d: %s",
+				  sec, offset + entry->new,
+				  new_reloc->sym->type,
+				  new_reloc->sym->name);
 			return -1;
 		}
 

  reply	other threads:[~2021-10-03 19:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-03  9:43 [GIT PULL] objtool/urgent for v5.15-rc4 Borislav Petkov
2021-10-03 18:20 ` pr-tracker-bot
2021-10-03 18:38 ` Linus Torvalds
2021-10-03 19:02   ` Linus Torvalds [this message]
2021-10-03 19:10     ` Linus Torvalds
2021-10-03 23:02       ` Josh Poimboeuf
2021-10-04  7:28         ` Paolo Bonzini

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='CAHk-=wiZwq-0LknKhXN4M+T8jbxn_2i9mcKpO+OaBSSq_Eh7tg@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=bp@suse.de \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.