CONFIG_FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY not supported on ppc64le

[joe-lawrence]

Trying to build a kpatch when CONFIG_FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY is set results in a complaint from create-diff-object that the "function ... has no fentry/mcount call, unable to patch".

[joe-lawrence]

issue-1382.tar.gz

See comparison of cmdline_proc_show() for when CONFIG_FTRACE_MCOUNT_USE_OBJTOOL vs CONFIG_FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY:

--- mcount_objtool      2024-03-25 15:31:39.819471809 -0400
+++ mcount_patchable_fun_entry  2024-03-25 15:32:10.441579666 -0400
@@ -5,7 +5,6 @@ Disassembly of section .text.cmdline_pro
                         0: R_PPC64_REL16_HA     .TOC.
    4:   00 00 42 38     addi    r2,r2,0
                         4: R_PPC64_REL16_LO     .TOC.+0x4
-   8:   a6 02 08 7c     mflr    r0
-   c:   01 00 00 48     bl      c <cmdline_proc_show+0xc>
-                        c: R_PPC64_REL24        _mcount
+   8:   00 00 00 60     nop
+   c:   00 00 00 60     nop
   10:   a6 02 08 7c     mflr    r0

The checks in kpatch_find_func_profiling_calls() for the PPC64 arch look for that "_mcount" relocation, which isn't present in the patchable-function-entry case.

To support this config, we could look for the nop instructions directly, like the S390 case, or maybe verify that there is a "patchable_function_entries" relocation for the function. This gets a little weird as the compiler seems to generate multiple __patchable_function_entries sections (one for each section?):

$ objdump -j__patchable_function_entries -r fs/proc/cmdline.o

fs/proc/cmdline.o:     file format elf64-powerpcle

RELOCATION RECORDS FOR [__patchable_function_entries]:
OFFSET           TYPE              VALUE
0000000000000000 R_PPC64_ADDR64    .init.text+0x0000000000000008


RELOCATION RECORDS FOR [__patchable_function_entries]:
OFFSET           TYPE              VALUE
0000000000000000 R_PPC64_ADDR64    .text.cmdline_proc_show+0x0000000000000008

[joe-lawrence]

repro-1382.tar.gz

[jpoimboe]

Multiple sections with the same name, weird :-) IMO, checking for the nops is probably sufficient.

[github-actions]

This issue has been open for 30 days with no activity and no assignee. It will be closed in 7 days unless a comment is added.

[github-actions]

This issue has been open for 30 days with no activity and no assignee. It will be closed in 7 days unless a comment is added.

[github-actions]

This issue was closed because it was inactive for 7 days after being marked stale.

[joe-lawrence]

Fixed by #1415