From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Longjun Luo <luolongjuna@gmail.com>
Cc: peterz@infradead.org, song@kernel.org, jikos@kernel.org,
pmladek@suse.com, live-patching@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] objtool/klp: Fix missed changes to same-named symbol references
Date: Sun, 13 Sep 2026 17:26:57 -0700 [thread overview]
Message-ID: <aqc5Q4_9bHpAI4jh@jpoimboe> (raw)
In-Reply-To: <20260910085218.66565-1-luolongjuna@gmail.com>
On Thu, Sep 10, 2026 at 04:52:18PM +0800, Longjun Luo wrote:
> Hashing symbol references by demangled_name alone can miss target
> changes while the instruction or data bytes and normalized relocation
> offsets remain unchanged. This occurs when:
>
> - A global function moves between files and calls a same-named static
> function with a different implementation.
> - A function's call target changes from a global function to a
> same-named static function, without moving the caller.
> - A data object, such as an ops structure, changes its function pointer
> from a global function to a same-named static function.
These seem like unusual edge cases, is this problem theoretical or was
it a real-world bug?
> +/* Include FILE identity to distinguish same-named local targets. */
> +static inline void __checksum_update_symbol_identity(struct symbol *sym,
> + struct symbol *target)
> +{
> + const char *file_name = target->file ? target->file->name : "";
> +
> + __checksum_update(sym, file_name, strlen(file_name) + 1);
> + __checksum_update(sym, target->demangled_name, strlen(target->demangled_name) + 1);
> +}
If the .patch upgrades a function from static to global then the
function no longer has a FILE associated with it. Then with the above,
all callers to that function would be marked as changed. And note that
LTO does a lot of that, so static-to-global and global-to-static changes
are common between orig and patched objects.
Note that function change detection isn't intended to be 100% perfect
for all edge cases. The patch author needs to verify the changed
function list matches what they expect.
--
Josh
next prev parent reply other threads:[~2026-09-14 0:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 8:52 [PATCH] objtool/klp: Fix missed changes to same-named symbol references Longjun Luo
2026-09-10 9:02 ` sashiko-bot
2026-09-10 9:32 ` Longjun Luo
2026-09-14 0:26 ` Josh Poimboeuf [this message]
2026-09-14 12:12 ` Longjun Luo
2026-09-14 19:55 ` Josh Poimboeuf
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=aqc5Q4_9bHpAI4jh@jpoimboe \
--to=jpoimboe@kernel.org \
--cc=jikos@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=luolongjuna@gmail.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=song@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.