Hi Joe,
Thanks for reviewing!
> Ok, what am I doing wrong here:
[...]
> What compiler / kernel config should I be trying with this patchset?
Nothing wrong on your side -- both things you hit are real bugs, thanks
for running the full flow. Fixes for both (and for the special-section
reloc issue you reported earlier) are queued for v3. Quick answers to
the compiler/config question:
Compiler:
- GCC: this is what the series was tested with, on real LoongArch
hardware (livepatch modules generated, loaded and exercised).
- LLVM: your clang 21 is fine. Note that klp-build itself requires
the LLVM assembler >= 20.
Config:
- defconfig plus your script is exactly right.
- The FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY select you added is
the proper fix, not a workaround: arch/loongarch/Makefile already
builds with -fpatchable-function-entry=2. v3 adds exactly that as
a patch, with your Reported-by/Suggested-by if that's ok with you.
On the "duplicate reloc" error: reproduced and fixed. The key field
of a __jump_table entry is a cross-section difference (".quad key - ."),
and clang's integrated assembler emits it as a relocation pair at the
same offset when the key is not defined in the same translation unit:
$ readelf -rW net/core/dev.o # clang 21.1.8
0x18 R_LARCH_ADD64 __tracepoint_netif_rx + 8
0x18 R_LARCH_SUB64 __jump_table + 0x18
Locally-defined keys (e.g. netstamp_needed_key) get a single
R_LARCH_64_PCREL instead, and GAS emits the single form in both cases,
which is why a GCC build never trips on this. objtool's
elf_create_reloc() allows only one relocation per offset, so cloning
such an entry fails on the SUB half.
The fix queued for v3 folds the pair into the single equivalent
R_LARCH_64_PCREL (which the module loader already supports). With it,
your exact test.patch now builds cleanly here with clang 21.1.8 on
LoongArch hardware; the tracepoint key correctly ends up as a klp
relocation against .klp.sym.vmlinux.__tracepoint_netif_rx.
Thanks,
George
