From: Petr Mladek <pmladek@suse.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
Miroslav Benes <mbenes@suse.cz>,
Sami Tolvanen <samitolvanen@google.com>,
Song Liu <song@kernel.org>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
jikos@kernel.org, joe.lawrence@redhat.com, nathan@kernel.org,
morbo@google.com, justinstitt@google.com,
thunder.leizhen@huawei.com, kees@kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH] kallsyms, livepatch: Fix livepatch with CONFIG_LTO_CLANG
Date: Thu, 4 Jul 2024 11:02:18 +0200 [thread overview]
Message-ID: <ZoZlGnVDzVONxUDs@pathway.suse.cz> (raw)
In-Reply-To: <ZoVumd-b4CaRu5nW@bombadil.infradead.org>
On Wed 2024-07-03 08:30:33, Luis Chamberlain wrote:
> On Tue, Jul 02, 2024 at 10:56:41PM -0700, Josh Poimboeuf wrote:
> > On Mon, Jul 01, 2024 at 03:13:23PM +0200, Petr Mladek wrote:
> > > So, you suggest to search the symbols by a hash. Do I get it correctly?
>
> I meant, that in the Rust world the symbols go over the allowed limit,
> and so an alternative for them is to just use a hash. What I'm
> suggesting is for a new kconfig option where that world is the
> new one, so that they have to also do the proper userspace tooling
> for it. Without that, I don't see it as properly tested or scalable.
> And if we're gonna have that option for Rust for modules, then it begs
> the question if this can be used by other users.
I am still not sure at which level the symbol names would get hashed ;-)
The symbols names are used in many situations, e.g. backtraces,
crashdump, objdump, nm, gdb, tracing, livepatching, kprobes, ...
Would kallsyms provide some translation table between the usual
"long" symbol name and a hash?
Would it allows to search the symbols both ways?
I am a bit scared because using hashed symbol names in backtraces, gdb,
... would be a nightmare. Hashes are not human readable and
they would complicate the life a lot. And using different names
in different interfaces would complicate the life either.
Best Regards,
Petr
next prev parent reply other threads:[~2024-07-04 9:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 3:21 [PATCH] kallsyms, livepatch: Fix livepatch with CONFIG_LTO_CLANG Song Liu
2024-06-07 13:06 ` Miroslav Benes
2024-06-07 16:53 ` Song Liu
2024-06-28 12:23 ` Miroslav Benes
2024-06-28 17:36 ` Luis Chamberlain
2024-06-28 19:31 ` Sami Tolvanen
2024-07-01 13:13 ` Petr Mladek
2024-07-03 5:56 ` Josh Poimboeuf
2024-07-03 15:30 ` Luis Chamberlain
2024-07-04 9:02 ` Petr Mladek [this message]
2024-07-08 21:33 ` Luis Chamberlain
2024-07-09 0:07 ` Sami Tolvanen
2024-07-09 16:42 ` Song Liu
2024-07-09 17:06 ` Matthew Maurer
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=ZoZlGnVDzVONxUDs@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mcgrof@kernel.org \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=samitolvanen@google.com \
--cc=song@kernel.org \
--cc=thunder.leizhen@huawei.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