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? Thanks, Longjun Josh Poimboeuf <[email protected]> 于2026年9月14日周一 08:27写道： > > 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
