Hi,
Steve pointed me at this thread over IRC -- I'm not subscribed to this list so
grabbed a copy of the thread thus far via b4.
On Tue, Jan 25, 2022 at 11:20:27AM +0800, Yinan Liu wrote:
> > Yeah, I think it's time to opt in, instead of opting out.
I agree this must be opt-in rather than opt-out.
However, I think most architectures were broken (in at least some
configurations) by commit:
72b3942a173c387b ("scripts: ftrace - move the sort-processing in ftrace_init")
... and so I don't think this fix is correct as-is, and we might want to revert
that or at least mark is as BROKEN for now.
More on that below.
> >
> > Something like this:
> >
> > -- Steve
> >
> > 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 && MMU
IIUC the 32-bit arm kernel can be relocated at boot time, so I don't believe
this is correct, and I believe any relocatable arm kernel has been broken since
htat was introduced.
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index c4207cf9bb17..7996548b2b27 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -166,6 +166,7 @@ config ARM64
> > select HAVE_ASM_MODVERSIONS
> > select HAVE_EBPF_JIT
> > select HAVE_C_RECORDMCOUNT
> > + select HAVE_BUILDTIME_MCOUNT_SORT
> > select HAVE_CMPXCHG_DOUBLE
> > select HAVE_CMPXCHG_LOCAL
> > select HAVE_CONTEXT_TRACKING
The arm64 kernel is relocatable by default, and has been broken since the
build-time sort was introduced -- I see ftrace test failures, and the
CONFIG_FTRACE_SORT_STARTUP_TEST screams at boot time.
> > diff --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
Isn't x86 relocatable in some configurations (e.g. for KASLR)?
I can't see how the sort works for those cases, because the mcount_loc entries
are absolute, and either:
* The sorted entries will get overwritten by the unsorted relocation entries,
and won't be sorted.
* The sorted entries won't get overwritten, but then the absolute address will
be wrong since they hadn't been relocated.
How does that work?
Thanks,
Mark.
> > select HAVE_DEBUG_KMEMLEAK
> > select HAVE_DMA_CONTIGUOUS
> > select HAVE_DYNAMIC_FTRACE
> > diff --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.
>
> LGTM. This will no longer destroy ftrace on other architectures.
> Those arches that we are not sure about can test and enable this function by
> themselves.
>
>
> Best regards
> --yinan
>
