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
