Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 14 Feb 2021 09:51:47 -0600
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Xi Ruoyao <xry111@mengyan1223.wang>,
        "# 3.4.x" <stable@vger.kernel.org>,
        Arnd Bergmann <arnd@kernel.org>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>,
        Miroslav Benes <mbenes@suse.cz>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-tip-commits@vger.kernel.org
Subject: Re: [tip: objtool/urgent] objtool: Fix seg fault with Clang
 non-section symbols
Message-ID: <20210214155147.3owdimqv2lyhu6by@treble>
References: <dded80b60d9136ea90987516c28f93273385651f.camel@mengyan1223.wang>
 <YCU3Vdoqd+EI+zpv@kroah.com>
 <CAKwvOd=GHdkvAU3u6ROSgtGqC_wrkXo8siL1nZHE-qsqSx0gsw@mail.gmail.com>
 <YCafKVSTX9MxDBMd@kroah.com>
 <20210212170750.y7xtitigfqzpchqd@treble>
 <20210212124547.1dcf067e@gandalf.local.home>
 <YCfdfkoeh8i0baCj@kroah.com>
 <20210213091304.2dd51e5f@oasis.local.home>
 <20210213155203.lehuegwc3h42nebs@treble>
 <YCf9bnsmXqRGMn+j@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <YCf9bnsmXqRGMn+j@kroah.com>
Precedence: bulk

On Sat, Feb 13, 2021 at 05:25:18PM +0100, Greg Kroah-Hartman wrote:
> On Sat, Feb 13, 2021 at 09:52:03AM -0600, Josh Poimboeuf wrote:
> > On Sat, Feb 13, 2021 at 09:13:04AM -0500, Steven Rostedt wrote:
> > > On Sat, 13 Feb 2021 15:09:02 +0100
> > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > 
> > > > Thanks for the patch, but no, still fails with:
> > > > 
> > > > Cannot find symbol for section 8: .text.unlikely.
> > > > kernel/kexec_file.o: failed
> > > > make[1]: *** [scripts/Makefile.build:277: kernel/kexec_file.o] Error 1
> > > > make[1]: *** Deleting file 'kernel/kexec_file.o'
> > > 
> > > It was just a guess.
> > > 
> > > I guess I'll need to find some time next week to set up a VM with
> > > binutils 2.36 (I just checked, and all my development machines have
> > > 2.35). Then I'll be able to try and debug it.
> > 
> > FWIW, I wasn't able to recreate.   I tried both binutils 2.36 and
> > 2.36.1, with gcc 11 and a 'make allmodconfig' kernel.
> 
> I'm using whatever the latest is in Arch, which is gcc 10.2 and binutils
> 2.36.  My config is here:
> 	https://github.com/gregkh/gregkh-linux/blob/master/stable/configs/4.4.y

Ok, I was able to recreate with that config.

GCC places two weak functions (arch_kexec_apply_relocations_add() and
arch_kexec_apply_relocations()) in .text.unlikely (probably because
printk() is __cold), and then the assembler doesn't generate the
'.text.unlikely' symbol because no other code references it.

Steve, looks like recordmcount avoids referencing weak symbols directly
by their function symbol.  Maybe it can just skip weak symbols which
don't have a section symbol, since this seems like a rare scenario.

Here's a total hack fix.  Just remove the functions, awkwardly avoiding
the problem.

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 6030efd4a188..456e3427c5e5 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -115,24 +115,6 @@ int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf,
 	return -EKEYREJECTED;
 }
 
-/* Apply relocations of type RELA */
-int __weak
-arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
-				 unsigned int relsec)
-{
-	pr_err("RELA relocation unsupported.\n");
-	return -ENOEXEC;
-}
-
-/* Apply relocations of type REL */
-int __weak
-arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
-			     unsigned int relsec)
-{
-	pr_err("REL relocation unsupported.\n");
-	return -ENOEXEC;
-}
-
 /*
  * Free up memory used by kernel, initrd, and command line. This is temporary
  * memory allocation which is not needed any more after these buffers have