Cumulative EL9 kernel livepatch build fails on unrelated files: CSWTCH renumbering, gcc inlining drift, missing R_X86_64_32, PVH boot code

[benjamindonnachie]

Summary

Building a real cumulative kpatch livepatch for AlmaLinux 9.8, kernel
5.14.0-687.25.1.el9_8 → 5.14.0-687.38.1.el9_8 (11 CVEs, kpatch at
6f27de9d873677ae441d6131df2a1ca97af6f834, current master), the build
failed deterministically on every attempt — not on any of the files the
patch series actually touches, but on ~40 unrelated files that
kpatch-build recompiled only because the patch series happens to touch
a widely-included header (arch/x86/include/asm/msr-index.h). Kbuild
recompiles anything it considers stale, not just what the patch touches.

Root-caused this to four independent issues, each with its own PR:

1. testing fedora 27: meminfo-cmdline-rebuild-SLOW: build failed #767-class CSWTCH/__compound_literal renumbering — gcc's
   numbering of compiler-synthesized read-only data isn't stable between
   kpatch-build's from-scratch "original" pass and its later, incrementally
   -triggered "patched" pass, even for byte-identical source (verified:
   compiling the same unmodified file twice standalone is byte-for-byte
   reproducible; it's specifically kpatch-build's two-pass sequence that
   exposes the drift). kpatch_find_static_twin()'s name/reference
   correlation fails closed on this even though the file is provably
   unchanged. → PR fixing create-diff-object.c.

2. find_local_syms() fails closed on unrelated files — gcc's
   inlining decisions (full or .part.N partial) for a handful of
   functions per file aren't always reproducible between a local rebuild
   and the officially published kernel build (most likely PGO/AutoFDO
   data the local rebuild doesn't have). This aborts the whole build the
   moment it happens for any recompiled file, not just ones with real
   patch content. → PR deferring this in lookup.c.

3. Missing R_X86_64_32 (ELF reloc type 10) in rela_target_offset()
   — only R_X86_64_32S was handled; R_X86_64_32 is likewise absolute
   (add_off=0 is correct per the x86-64 psABI) but hits
   ERROR("unhandled rela type %d"). Shows up in code that still runs in
   32-bit protected mode before switching to long mode (observed in
   arch/x86/platform/pvh/head.o). → PR fixing kpatch-elf.c.

4. arch/x86/platform/pvh/* missing from kpatch-cc's exclusion list
   — this is Xen PVH boot entry code, runs once at very early boot before
   livepatch infrastructure is even up, so it can never legitimately be
   part of any livepatch. The same category of code
   (arch/x86/boot/*, arch/x86/realmode/*, arch/x86/purgatory/*, the
   EFI stub, etc.) is already excluded; this one entry was just missing.
   → PR fixing kpatch-cc.

Validation

All four fixes together took the build from failing deterministically
(41 → 40 → 37 → 1 → 0 blocking errors across iterations of just the
CSWTCH/inlining/rela fixes) through to a working .ko module, correctly
covering all 11 target CVEs (confirmed via kpatch list after installing
the built RPM on the build host), and a clean RPM build.

Filing as one issue with four linked, independently-reviewable PRs since
each fix stands on its own and none depend on the others.

Co-authored-by: Claude noreply@anthropic.com