Re: [PATCH v2 3/7] objtool/klp: Ignore replacement offset of empty x86 alternatives

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