Re: [PATCH] objtool/klp: Fix missed changes to same-named symbol references

[Josh Poimboeuf <jpoimboe@kernel.org>]

On Mon, Sep 14, 2026 at 08:12:33PM +0800, Longjun Luo wrote:
> Hi Josh,
> 
> > These seem like unusual edge cases, is this problem theoretical or was
> > it a real-world bug?
> 
> These are constructed reproducers, not production failures. We have
> been working on userspace livepatching, including symbol correlation
> under LTO. I built and tested these cases while comparing klp-build
> and kpatch-build.
> 
> > 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.
> 
> I confirmed locally that kernel LTO can change a function's binding
> without changing its name.
> 
> For context, in our userspace ThinLTO tests, promoted locals usually
> acquired a .llvm.<hash> suffix. The kernel's ThinLTO build uses
> -always-rename-promoted-locals=false when supported by the toolchain,
> so promotion need not add that suffix.
> 
> I agree that this FILE-based checksum change is too restrictive.
> Please drop this patch.
> 
> You are right that patch authors need to verify the changed-function
> list. However, in these cases the current checksums do not distinguish
> the old and new targets, and no diagnostic points to the missed change.
> That could make a resulting problem difficult and time-consuming to
> diagnose. Would it be useful to document these cases as a known
> limitation?

Yes, and in fact we need a "patch author guide" for humans/LLMs to read
when using klp-build, as there are pitfalls to watch out for.

Something similar to what kpatch has...

  https://github.com/dynup/kpatch/blob/master/doc/patch-author-guide.md

in case anybody wants to try porting that over.

-- 
Josh