From: Baoquan He <bhe@redhat.com>
To: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org,
"Eric W. Biederman" <ebiederm@xmission.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kexec_file: Drop pr_err in weak implementations of arch_kexec_apply_relocations[_add]
Date: Wed, 18 May 2022 18:11:41 +0800 [thread overview]
Message-ID: <YoTGXQvQutAR5PZY@MiWiFi-R3L-srv> (raw)
In-Reply-To: <1652864763.xpq371r1wx.naveen@linux.ibm.com>
On 05/18/22 at 02:48pm, Naveen N. Rao wrote:
> Baoquan He wrote:
> > On 05/18/22 at 12:26pm, Michael Ellerman wrote:
> > >
> > > It seems that recordmcount is not really maintained anymore now that x86
> > > uses objtool?
> > >
> > > There've been several threads about fixing recordmcount, but none of
> > > them seem to have lead to a solution.
> > >
> > > These weak symbol vs recordmcount problems have been worked around going
> > > back as far as 2020:
> >
> > It gives me feeling that llvm or recordmcount should make adjustment,
> > but not innocent kernel code, if there are a lot of places reported.
> > I am curious how llvm or recordmcount dev respond to this.
>
> As Michael stated, this is not just llvm - binutils has also adopted the
> same and "unused" section symbols are being dropped.
>
> For recordmcount, there were a few threads and approaches that have been
> tried:
> - https://patchwork.ozlabs.org/project/linuxppc-dev/patch/cd0f6bdfdf1ee096fb2c07e7b38940921b8e9118.1637764848.git.christophe.leroy@csgroup.eu/
> - https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=297434&state=*
>
> Objtool has picked up a more appropriate fix for this recently, and
> long-term, we would like to move to using objtool for ftrace purposes:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/objtool/elf.c?id=4abff6d48dbcea8200c7ea35ba70c242d128ebf3
>
> While that is being pursued, we want to unbreak some of the CI and users who
> are hitting this.
I see, thanks for the details. I would persue fix in recordmcount if
possible, while has no objection to fix it in kernel with justification
if have to. Given my limited linking knowledge, leave this to other
expert to decide.
next prev parent reply other threads:[~2022-05-18 10:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-25 17:41 [PATCH] kexec_file: Drop pr_err in weak implementations of arch_kexec_apply_relocations[_add] Naveen N. Rao
2022-05-17 7:58 ` Naveen N. Rao
2022-05-17 9:25 ` Baoquan He
2022-05-17 10:19 ` Naveen N. Rao
2022-05-17 15:32 ` Eric W. Biederman
2022-05-18 2:26 ` Michael Ellerman
2022-05-18 7:49 ` Baoquan He
2022-05-18 9:18 ` Naveen N. Rao
2022-05-18 10:11 ` Baoquan He [this message]
2022-05-18 14:48 ` Eric W. Biederman
2022-05-18 16:48 ` Naveen N. Rao
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=YoTGXQvQutAR5PZY@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=naveen.n.rao@linux.vnet.ibm.com \
/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).