[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABCJKucLzNB+kd5UEOzUrTU36_vgtPVb-rQyf_d0kNtNjh2UkA@mail.gmail.com>
Date: Fri, 28 Jun 2024 12:31:41 -0700
From: Sami Tolvanen <samitolvanen@...gle.com>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: Miroslav Benes <mbenes@...e.cz>, Song Liu <song@...nel.org>, live-patching@...r.kernel.org,
linux-kernel@...r.kernel.org, jpoimboe@...nel.org, jikos@...nel.org,
pmladek@...e.com, joe.lawrence@...hat.com, nathan@...nel.org,
morbo@...gle.com, justinstitt@...gle.com, thunder.leizhen@...wei.com,
kees@...nel.org, kernel-team@...a.com
Subject: Re: [PATCH] kallsyms, livepatch: Fix livepatch with CONFIG_LTO_CLANG
Hi Luis,
On Fri, Jun 28, 2024 at 10:36 AM Luis Chamberlain <mcgrof@...nel.org> wrote:
>
> On Fri, Jun 28, 2024 at 02:23:49PM +0200, Miroslav Benes wrote:
> > On Fri, 7 Jun 2024, Song Liu wrote:
> >
> > > Hi Miroslav,
> > >
> > > Thanks for reviewing the patch!
> > >
> > > I think it is possible. Currently, kallsyms_on_each_match_symbol matches
> > > symbols without the postfix. We can add a variation or a parameter, so
> > > that it matches the full name with post fix.
> >
> > I think it might be better.
> >
> > Luis, what is your take on this?
> >
> > If I am not mistaken, there was a patch set to address this. Luis might
> > remember more.
>
> Yeah this is a real issue outside of CONFIG_LTO_CLANG, Rust modules is
> another example where instead of symbol names they want to use full
> hashes. So, as I hinted to you Sami, can we knock two birds with one stone
> here and move CONFIG_LTO_CLANG to use the same strategy as Rust so we
> have two users instead of just one?
I'm all for finding generic solutions, but perhaps I've missed the
patch set Miroslav mentioned because I'm not quite sure how these
problems are related.
LTO makes duplicate symbol names globally unique by appending a
postfix to them, which complicates looking up symbols by name. Rust,
on the other hand, has a problem with CONFIG_MODVERSIONS because the
long symbol names it generates cannot fit in the small buffer in
struct modversion_info. The only reason we proposed storing a
cryptographic hash in modversion_info was to avoid breaking userspace
tools that parse this data structure, but AFAIK nobody wants to use
hashed symbol names anywhere else. In fact, if there's a better
solution for addressing modversion_info limitations, I would be happy
not to hash anything.
Sami
Powered by blists - more mailing lists