Re: [PATCH] ftrace: Have architectures opt-in for mcount build time sorting
From: Joe Lawrence <joe.lawrence@redhat.com>
Date: 2022-01-28 21:11:54
Also in:
linux-arm-kernel, lkml
On Thu, Jan 27, 2022 at 11:42:49AM -0500, Steven Rostedt wrote:
quoted hunk ↗ jump to hunk
From: "Steven Rostedt (Google)" <rostedt@goodmis.org> First S390 complained that the sorting of the mcount sections at build time caused the kernel to crash on their architecture. Now PowerPC is complaining about it too. And also ARM64 appears to be having issues. It may be necessary to also update the relocation table for the values in the mcount table. Not only do we have to sort the table, but also update the relocations that may be applied to the items in the table. If the system is not relocatable, then it is fine to sort, but if it is, some architectures may have issues (although x86 does not as it shifts all addresses the same). Add a HAVE_BUILDTIME_MCOUNT_SORT that an architecture can set to say it is safe to do the sorting at build time. Also update the config to compile in build time sorting in the sorttable code in scripts/ to depend on CONFIG_BUILDTIME_MCOUNT_SORT. Link: https://lore.kernel.org/all/944D10DA-8200-4BA9-8D0A-3BED9AA99F82@linux.ibm.com/ (local) Cc: Mark Rutland <mark.rutland@arm.com> Cc: Yinan Liu <redacted> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Kees Cook <redacted> Cc: linuxppc-dev@lists.ozlabs.org Reported-by: Sachin Sant <redacted> Tested-by: Sachin Sant <redacted> Fixes: 72b3942a173c ("scripts: ftrace - move the sort-processing in ftrace_init") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> --- arch/arm/Kconfig | 1 + arch/x86/Kconfig | 1 + kernel/trace/Kconfig | 8 +++++++- scripts/Makefile | 2 +- 4 files changed, 10 insertions(+), 2 deletions(-)diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c2724d986fa0..5256ebe57451 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig@@ -82,6 +82,7 @@ config ARM select HAVE_EBPF_JIT if !CPU_ENDIAN_BE32 select HAVE_CONTEXT_TRACKING select HAVE_C_RECORDMCOUNT + select HAVE_BUILDTIME_MCOUNT_SORT select HAVE_DEBUG_KMEMLEAK if !XIP_KERNEL select HAVE_DMA_CONTIGUOUS if MMU select HAVE_DYNAMIC_FTRACE if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMUdiff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 7399327d1eff..46080dea5dba 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig@@ -186,6 +186,7 @@ config X86 select HAVE_CONTEXT_TRACKING_OFFSTACK if HAVE_CONTEXT_TRACKING select HAVE_C_RECORDMCOUNT select HAVE_OBJTOOL_MCOUNT if STACK_VALIDATION + select HAVE_BUILDTIME_MCOUNT_SORT select HAVE_DEBUG_KMEMLEAK select HAVE_DMA_CONTIGUOUS select HAVE_DYNAMIC_FTRACEdiff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index 752ed89a293b..7e5b92090faa 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig@@ -70,10 +70,16 @@ config HAVE_C_RECORDMCOUNT help C version of recordmcount available? +config HAVE_BUILDTIME_MCOUNT_SORT + bool + help + An architecture selects this if it sorts the mcount_loc section + at build time. + config BUILDTIME_MCOUNT_SORT bool default y - depends on BUILDTIME_TABLE_SORT && !S390 + depends on HAVE_BUILDTIME_MCOUNT_SORT help Sort the mcount_loc section at build time.diff --git a/scripts/Makefile b/scripts/Makefile index b082d2f93357..cedc1f0e21d8 100644 --- a/scripts/Makefile +++ b/scripts/Makefile@@ -32,7 +32,7 @@ HOSTCFLAGS_sorttable.o += -I$(srctree)/tools/arch/x86/include HOSTCFLAGS_sorttable.o += -DUNWINDER_ORC_ENABLED endif -ifdef CONFIG_DYNAMIC_FTRACE +ifdef CONFIG_BUILDTIME_MCOUNT_SORT HOSTCFLAGS_sorttable.o += -DMCOUNT_SORT_ENABLED endif --2.33.0
Hi Steve,
I just finished bisecting what is probably the same problem... when
running the livepatch selftests for 5.17-rc1, x86_64 passes, but I kept
getting errors like this on ppc64le:
kernel: livepatch: enabling patch 'test_klp_livepatch'
kernel: livepatch: failed to find location for function 'cmdline_proc_show'
kernel: livepatch: failed to patch object 'vmlinux'
kernel: livepatch: failed to enable patch 'test_klp_livepatch'
kernel: livepatch: 'test_klp_livepatch': unpatching complete
which means klp_get_ftrace_location() / ftrace_location_range() hit a
problem with that function.
The bisect finally landed on:
72b3942a173c387b27860ba1069636726e208777 is the first bad commit
commit 72b3942a173c387b27860ba1069636726e208777
Author: Yinan Liu [off-list ref]
Date: Sun Dec 12 19:33:58 2021 +0800
scripts: ftrace - move the sort-processing in ftrace_init
and I can confirm that your updates today in "[for-linus][PATCH 00/10]
tracing: Fixes for 5.17-rc1" fix or avoid the issue. I just wanted to
add my report in case this adds any future complications for mcount
build time sorting. Let me know if any additional tests would be
helpful.
Regards,
-- Joe