On Wed, Aug 5, 2026 at 7:30 AM Josh Poimboeuf <[email protected]> wrote: > > An x86 alternative with an empty replacement, e.g. the second entry of > > ALTERNATIVE_2("orig", "repl", ft1, "", ft2) > > has a replacementlen of zero. Its replacement offset still gets a > relocation, but the label it points at is the end of the previous > replacement, which is also the beginning of the *next* alternative's > replacement. The value is meaningless; get_alt_entry() already ignores > it for that reason. > > klp diff doesn't ignore it. When such an alternative belongs to a > changed function, cloning its relocations drags in the unrelated > neighboring replacement, along with everything that replacement > references. On an x86 clang/lto build an empty alternative in > meminfo_proc_show() pulled in the replacement of an alternative in > proc_kcore_init(), silently emitting a klp relocation against init text > which has long since been freed by the time the patch is applied. > > Add arch_alt_ignore_new_reloc() and skip such relocations when cloning. > This has to be arch specific: on arm64 a zero-length replacement instead > identifies an alternative callback, whose replacement offset points at > the callback function and must be preserved. > > Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing > object files") > Signed-off-by: Josh Poimboeuf <[email protected]>
The patch looks good to me. Acked-by: Song Liu <[email protected]> Maybe we should add a __weak version of arch_alt_ignore_new_reloc(), but that can wait until we add arm64 support. However, this reminds me the cross compile use case. With current arch_* functions, we cannot run klp-build on x86_64 build server for an arm64 kernel (right?). What's our plan with the cross-compile use cases? Thanks, Song
