kernel/trace/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
From: Steven Rostedt <rostedt@goodmis.org>
ftrace has two flavors:
1) static: Where every function always calls the ftrace trampoline
2) dynamic: Where each function has nops that can be changed on demand to
jump to the ftrace trampoline when needed.
The static flavor has very high performance overhead and was only created
to make it easier for architectures to implement the dynamic flavor. An
architecture developer can first implement the static ftrace to make sure
the trampolines work before working on the more complicated dynamic aspect
of ftrace. Once the architecture can support dynamic ftrace, there's no
reason to continue to support the static flavor. In fact, the static
flavor tends to bitrot and bugs start to appear in them.
Remove the prompt to pick DYNAMIC_FTRACE and simply enable it if the
architecture supports it.
Link: https://lore.kernel.org/all/f7e12c6d-892e-4ca3-9ef0-fbb524d04a48@ghiti.fr/
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
kernel/trace/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index a3f35c7d83b6..28afc6941e7a 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -275,7 +275,7 @@ config FUNCTION_TRACE_ARGS
funcgraph-args (for the function graph tracer)
config DYNAMIC_FTRACE
- bool "enable/disable function tracing dynamically"
+ bool
depends on FUNCTION_TRACER
depends on HAVE_DYNAMIC_FTRACE
default y
--
2.47.2
On Thu, 3 Jul 2025 at 08:52, Steven Rostedt <rostedt@goodmis.org> wrote: > > Remove the prompt to pick DYNAMIC_FTRACE and simply enable it if the > architecture supports it. I don't disagree with removing pointless Kconfig options, but if we do this, we should do it properly. Because now we have that entirely pointless "HAVE_DYNAMIC_FTRACE*" set of config options. Which with this patch would be just stupid and extra indirection that makes things harder to see. IOW, with this patch we'd have (a) architectures that support dynamic ftrace will do select HAVE_DYNAMIC_FTRACE select HAVE_DYNAMIC_FTRACE_WITH_REGS (or whatever combination) and then (b) kernel/trace/Kconfig will just turn that into the proper DYNAMIC_FTRACE_xyz macros and when this no longer involves any questions, there is absolutely *zero* reason I can see for that pointless indirection through another config variables. Yes, yes, there's still the "depends on FUNCTION_TRACER" that technically is a "reason" for that indirection, but it seems to be a reall ybad one. IOW, I think that if we do this, we should just get rid of the "HAVE_DYNAMIC_FTRACE{_XYZ}" config variables entirely, and just make architectures say select DYNAMIC_FTRACE if FUNCTION_TRACER because the "HAVE_xyz" config variables seem to add no actual value, only confusion. Or am I missing some reason for still having that extra config variable indirection? Linus
On Thu, 3 Jul 2025 09:57:37 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote: > IOW, I think that if we do this, we should just get rid of the > "HAVE_DYNAMIC_FTRACE{_XYZ}" config variables entirely, and just make > architectures say > > select DYNAMIC_FTRACE if FUNCTION_TRACER > > because the "HAVE_xyz" config variables seem to add no actual value, > only confusion. > > Or am I missing some reason for still having that extra config > variable indirection? I always thought the "HAVE_" configs was a way for architectures to state that it supports something but doesn't necessarily enable it. Whereas the not "HAVE_" configs are user selectable. If I go and make all the architectures have: select DYNAMIC_FTRACE if FUNCTION_TRACER it seems to be duplicating the work, where all the architectures need to know the dependencies. To me, that belongs in the generic configs. The FUNCTION_TRACER config is user selectable, and DYNMIC_FTRACE gets set when the arch supports dynamic ftrace and the user enables function tracing. Now, I probably could go and try to clean up some of the HAVE_FTRACE_* configs. Ftrace has a lot of code that is tightly coupled to architecture specific code because it relies on trampolines written in assembly. Throughout the years, I added new features and optimizations that required architecture fixes. As a lot of the architectures support ftrace but I have no idea how to update them, I implemented the change in x86 and added a HAVE_FTRACE_* config so that other architectures could have time to update to the new feature too and the old way still works. I should look to see what hasn't been ported to every architecture that supports ftrace and remove the configs that are now universal. -- Steve
" part On Thu, 3 Jul 2025 at 12:26, Steven Rostedt <rostedt@goodmis.org> wrote: > > I always thought the "HAVE_" configs was a way for architectures to state > that it supports something but doesn't necessarily enable it. Whereas the > not "HAVE_" configs are user selectable. I don't actually think we have those kinds of rules in practice. We have very random Kconfig things. A lot of things are "architecture just selects the feature directly", and the naming is a random collection of ARCH_HAS_abc, ARCH_USE_abc, ARCH_WANT_abc, HAVE_ARCH_abc and HAVE_abc. And those are the patterns that _try_ to be some kind of pattern, and ignores all the "architecture just selects the feature directly". Honestly, when we have *five* different syntaxes for "this architecture supports feature 'abc'", I'd argue that not only isn't there a standard way, all those different syntax forms are just confusing. I get the strong feeling that the reason people have those different prefixes is literally to just group things together alphabetically - ie some people use "ARCH_HAS_xyz" just because that way they can put the "select" statement next to another ARCH_HAS_xyz that they also maintain. And then in addition to those various "arch has", we have the "GENERIC_xyz" Kconfig entries that architectures also select. I think those GENERIC_xyz Kconfig options may actually have more of a pattern: that _tends_ to be about "I'm not implementing my own version, please just pick the generic version". That one is one of our better patterns, I think. So the reason I dislike the HAVE_xyz pattern is exactly that there _isn't_ a pattern. When there are fifteen different patterns, it's not a pattern at all. That said, maybe it's better to have one place that has that "if FUNCTION_TRACER, even if I despise the nonsensical "helper indirection" just because of the random naming. Linus
On Thu, 3 Jul 2025 13:58:17 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote: > So the reason I dislike the HAVE_xyz pattern is exactly that there > _isn't_ a pattern. When there are fifteen different patterns, it's not > a pattern at all. > > That said, maybe it's better to have one place that has that "if > FUNCTION_TRACER, even if I despise the nonsensical "helper > indirection" just because of the random naming. At least with HAVE_FTRACE_* there is a pattern. The HAVE_* may not be consistent across other parts of the kernel, but it has been with ftrace. As I have stated, ftrace is very tightly coupled with the architectures due to the assembly written trampolines. And having a simple way for the architectures to denote what it supports and what it does not makes the generic code much simpler to implement. -- Steve
On Thu, 3 Jul 2025 15:26:43 -0400 Steven Rostedt <rostedt@goodmis.org> wrote: > I should look to see what hasn't been ported to every architecture that > supports ftrace and remove the configs that are now universal. HAVE_FTRACE_MCUONT_RECORD looks like a candidate for removal: $ git grep -e HAVE_FTRACE_MCOUNT -e HAVE_FUNCTION_TRACER arch arch/arm/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL arch/arm/Kconfig: select HAVE_FUNCTION_TRACER if !XIP_KERNEL arch/arm64/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD arch/arm64/Kconfig: select HAVE_FUNCTION_TRACER arch/csky/Kconfig: select HAVE_FUNCTION_TRACER arch/csky/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD arch/loongarch/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD arch/loongarch/Kconfig: select HAVE_FUNCTION_TRACER arch/microblaze/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD arch/microblaze/Kconfig: select HAVE_FUNCTION_TRACER arch/mips/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD arch/mips/Kconfig: select HAVE_FUNCTION_TRACER arch/parisc/Kconfig: select HAVE_FUNCTION_TRACER arch/parisc/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD if HAVE_DYNAMIC_FTRACE arch/powerpc/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD arch/powerpc/Kconfig: select HAVE_FUNCTION_TRACER if !COMPILE_TEST && (PPC64 || (PPC32 && CC_IS_GCC)) arch/riscv/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL arch/riscv/Kconfig: select HAVE_FUNCTION_TRACER if !XIP_KERNEL arch/s390/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD arch/s390/Kconfig: select HAVE_FUNCTION_TRACER arch/sh/Kconfig: select HAVE_FUNCTION_TRACER arch/sh/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD arch/sparc/Kconfig: select HAVE_FUNCTION_TRACER arch/sparc/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD arch/x86/Kconfig: select HAVE_FTRACE_MCOUNT_RECORD arch/x86/Kconfig: select HAVE_FUNCTION_TRACER arch/xtensa/Kconfig: select HAVE_FUNCTION_TRACER HAVE_FTRACE_MCOUNT_RECORD only means something if HAVE_FUNCTION_TRACER is set. Arm and riscv have the same dependencies for both. It is also only meaningful for HAVE_DYNAMIC_FTRACE, so parisc is fine. But it appears that xtensa is the only one that doesn't select it. But it is also the only arch that doesn't support DYNAMIC_FTRACE either so that's fine. The HAVE_FTRACE_MCOUNT_RECORD can be replaced by HAVE_DYNAMIC_FTRACE, as MCOUNT_RECORD is what is used to create the sections needed for DYNAMIC_FTRACE. In fact the config has: config FTRACE_MCOUNT_RECORD def_bool y depends on DYNAMIC_FTRACE depends on HAVE_FTRACE_MCOUNT_RECORD Now this config is only used for adding a section in vmlinux.lds. Thus, we can remove the MCOUNT_RECORD configs and just use CONFIG_DYNAMIC_FTRACE instead. Something like below. I haven tested it. I would need to compile every arch. But I think this would work. -- Steve diff --git a/Documentation/trace/ftrace-design.rst b/Documentation/trace/ftrace-design.rst index dc82d64b3a44..8f4fab3f9324 100644 --- a/Documentation/trace/ftrace-design.rst +++ b/Documentation/trace/ftrace-design.rst @@ -238,19 +238,15 @@ You need very few things to get the syscalls tracing in an arch. - Tag this arch as HAVE_SYSCALL_TRACEPOINTS. -HAVE_FTRACE_MCOUNT_RECORD -------------------------- +HAVE_DYNAMIC_FTRACE +------------------- See scripts/recordmcount.pl for more info. Just fill in the arch-specific details for how to locate the addresses of mcount call sites via objdump. This option doesn't make much sense without also implementing dynamic ftrace. - -HAVE_DYNAMIC_FTRACE -------------------- - -You will first need HAVE_FTRACE_MCOUNT_RECORD and HAVE_FUNCTION_TRACER, so -scroll your reader back up if you got over eager. +You will first need HAVE_FUNCTION_TRACER, so scroll your reader back up if you +got over eager. Once those are out of the way, you will need to implement: - asm/ftrace.h: diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3072731fe09c..33cc9dbb7f68 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -107,7 +107,6 @@ config ARM select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU select HAVE_EXIT_THREAD select HAVE_GUP_FAST if ARM_LPAE - select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL select HAVE_FUNCTION_ERROR_INJECTION select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_TRACER if !XIP_KERNEL diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 55fc331af337..f943a07db139 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -223,7 +223,6 @@ config ARM64 select HAVE_EFFICIENT_UNALIGNED_ACCESS select HAVE_GUP_FAST select HAVE_FTRACE_GRAPH_FUNC - select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_TRACER select HAVE_FUNCTION_ERROR_INJECTION select HAVE_FUNCTION_GRAPH_FREGS diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig index acc431c331b0..4331313a42ff 100644 --- a/arch/csky/Kconfig +++ b/arch/csky/Kconfig @@ -80,7 +80,6 @@ config CSKY select HAVE_FUNCTION_TRACER select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_ERROR_INJECTION - select HAVE_FTRACE_MCOUNT_RECORD select HAVE_KERNEL_GZIP select HAVE_KERNEL_LZO select HAVE_KERNEL_LZMA diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig index 4b19f93379a1..bead8266dc5c 100644 --- a/arch/loongarch/Kconfig +++ b/arch/loongarch/Kconfig @@ -144,7 +144,6 @@ config LOONGARCH select HAVE_EXIT_THREAD select HAVE_GUP_FAST select HAVE_FTRACE_GRAPH_FUNC - select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_ARG_ACCESS_API select HAVE_FUNCTION_ERROR_INJECTION select HAVE_FUNCTION_GRAPH_FREGS diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index f18ec02ddeb2..484ebb3baedf 100644 --- a/arch/microblaze/Kconfig +++ b/arch/microblaze/Kconfig @@ -28,7 +28,6 @@ config MICROBLAZE select HAVE_DEBUG_KMEMLEAK select HAVE_DMA_CONTIGUOUS select HAVE_DYNAMIC_FTRACE - select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_TRACER select HAVE_PAGE_SIZE_4KB diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 1e48184ecf1e..268730824f75 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -73,7 +73,6 @@ config MIPS select HAVE_EBPF_JIT if !CPU_MICROMIPS select HAVE_EXIT_THREAD select HAVE_GUP_FAST - select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_TRACER select HAVE_GCC_PLUGINS diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index fcc5973f7519..2efa4b08b7b8 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -81,7 +81,6 @@ config PARISC select HAVE_KPROBES select HAVE_KRETPROBES select HAVE_DYNAMIC_FTRACE if $(cc-option,-fpatchable-function-entry=1,1) - select HAVE_FTRACE_MCOUNT_RECORD if HAVE_DYNAMIC_FTRACE select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY if DYNAMIC_FTRACE select HAVE_KPROBES_ON_FTRACE select HAVE_DYNAMIC_FTRACE_WITH_REGS diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index c3e0cc83f120..cb4fb8d73300 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -246,7 +246,6 @@ config PPC select HAVE_EFFICIENT_UNALIGNED_ACCESS select HAVE_GUP_FAST select HAVE_FTRACE_GRAPH_FUNC - select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_ARG_ACCESS_API select HAVE_FUNCTION_DESCRIPTORS if PPC64_ELF_ABI_V1 select HAVE_FUNCTION_ERROR_INJECTION diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 36061f4732b7..cd1cec255015 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -158,7 +158,6 @@ config RISCV select HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS if (DYNAMIC_FTRACE_WITH_ARGS && !CFI_CLANG) select HAVE_DYNAMIC_FTRACE_WITH_ARGS if HAVE_DYNAMIC_FTRACE select HAVE_FTRACE_GRAPH_FUNC - select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL select HAVE_FUNCTION_GRAPH_TRACER if HAVE_DYNAMIC_FTRACE_WITH_ARGS select HAVE_FUNCTION_GRAPH_FREGS select HAVE_FUNCTION_TRACER if !XIP_KERNEL diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 0c16dc443e2f..d956e85f0465 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -199,7 +199,6 @@ config S390 select HAVE_GUP_FAST select HAVE_FENTRY select HAVE_FTRACE_GRAPH_FUNC - select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_ARG_ACCESS_API select HAVE_FUNCTION_ERROR_INJECTION select HAVE_FUNCTION_GRAPH_FREGS diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 89185af7bcc9..d5795067befa 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -40,7 +40,6 @@ config SUPERH select HAVE_GUP_FAST if MMU select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_TRACER - select HAVE_FTRACE_MCOUNT_RECORD select HAVE_HW_BREAKPOINT select HAVE_IOREMAP_PROT if MMU && !X2TLB select HAVE_KERNEL_BZIP2 diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index 0f88123925a4..f307e730446c 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -78,7 +78,6 @@ config SPARC64 select MMU_GATHER_NO_FLUSH_CACHE select HAVE_ARCH_TRANSPARENT_HUGEPAGE select HAVE_DYNAMIC_FTRACE - select HAVE_FTRACE_MCOUNT_RECORD select HAVE_PAGE_SIZE_8KB select HAVE_SYSCALL_TRACEPOINTS select HAVE_CONTEXT_TRACKING_USER diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5862433c81e1..2fc0d54ce634 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -244,7 +244,6 @@ config X86 select HAVE_GUP_FAST select HAVE_FENTRY if X86_64 || DYNAMIC_FTRACE select HAVE_FTRACE_GRAPH_FUNC if HAVE_FUNCTION_GRAPH_TRACER - select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_GRAPH_FREGS if HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_GRAPH_TRACER if X86_32 || (X86_64 && DYNAMIC_FTRACE) select HAVE_FUNCTION_TRACER diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index fa5f19b8d53a..ae2d2359b79e 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -167,7 +167,7 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG) #define FTRACE_STUB_HACK #endif -#ifdef CONFIG_FTRACE_MCOUNT_RECORD +#ifdef CONFIG_DYNAMIC_FTRACE /* * The ftrace call sites are logged to a section whose name depends on the * compiler option used. A given kernel image will only use one, AKA diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h index b672ca15f265..7ded7df6e9b5 100644 --- a/include/linux/ftrace.h +++ b/include/linux/ftrace.h @@ -1108,7 +1108,7 @@ static __always_inline unsigned long get_lock_parent_ip(void) # define trace_preempt_off(a0, a1) do { } while (0) #endif -#ifdef CONFIG_FTRACE_MCOUNT_RECORD +#ifdef CONFIG_DYNAMIC_FTRACE extern void ftrace_init(void); #ifdef CC_USING_PATCHABLE_FUNCTION_ENTRY #define FTRACE_CALLSITE_SECTION "__patchable_function_entries" diff --git a/include/linux/kernel.h b/include/linux/kernel.h index 1cce1f6410a9..989315dabb86 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -373,9 +373,9 @@ ftrace_vprintk(const char *fmt, va_list ap) static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { } #endif /* CONFIG_TRACING */ -/* Rebuild everything on CONFIG_FTRACE_MCOUNT_RECORD */ -#ifdef CONFIG_FTRACE_MCOUNT_RECORD -# define REBUILD_DUE_TO_FTRACE_MCOUNT_RECORD +/* Rebuild everything on CONFIG_DYNAMIC_FTRACE */ +#ifdef CONFIG_DYNAMIC_FTRACE +# define REBUILD_DUE_TO_DYNAMIC_FTRACE #endif /* Permissions on a sysfs file: you didn't miss the 0 prefix did you? */ diff --git a/include/linux/module.h b/include/linux/module.h index 5faa1fb1f4b4..800e6fde9bf7 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -539,7 +539,7 @@ struct module { struct trace_eval_map **trace_evals; unsigned int num_trace_evals; #endif -#ifdef CONFIG_FTRACE_MCOUNT_RECORD +#ifdef CONFIG_DYNAMIC_FTRACE unsigned int num_ftrace_callsites; unsigned long *ftrace_callsites; #endif diff --git a/include/linux/unwind_deferred.h b/include/linux/unwind_deferred.h index 515d2995672d..14efd8c027aa 100644 --- a/include/linux/unwind_deferred.h +++ b/include/linux/unwind_deferred.h @@ -28,8 +28,8 @@ void unwind_deferred_cancel(struct unwind_work *work); static __always_inline void unwind_reset_info(void) { - if (unlikely(current->unwind_info.id)) - current->unwind_info.id = 0; + if (unlikely(current->unwind_info.id.id)) + current->unwind_info.id.id = 0; /* * As unwind_user_faultable() can be called directly and * depends on nr_entries being cleared on exit to user, diff --git a/kernel/module/main.c b/kernel/module/main.c index 413ac6ea3702..58d36f8cef0d 100644 --- a/kernel/module/main.c +++ b/kernel/module/main.c @@ -2639,7 +2639,7 @@ static int find_module_sections(struct module *mod, struct load_info *info) sizeof(*mod->trace_bprintk_fmt_start), &mod->num_trace_bprintk_fmt); #endif -#ifdef CONFIG_FTRACE_MCOUNT_RECORD +#ifdef CONFIG_DYNAMIC_FTRACE /* sechdrs[0].sh_size is always zero */ mod->ftrace_callsites = section_objs(info, FTRACE_CALLSITE_SECTION, sizeof(*mod->ftrace_callsites), diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index a3f35c7d83b6..c2ce834313a9 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -74,11 +74,6 @@ config HAVE_DYNAMIC_FTRACE_NO_PATCHABLE If the architecture generates __patchable_function_entries sections but does not want them included in the ftrace locations. -config HAVE_FTRACE_MCOUNT_RECORD - bool - help - See Documentation/trace/ftrace-design.rst - config HAVE_SYSCALL_TRACEPOINTS bool help @@ -803,27 +798,22 @@ config BPF_KPROBE_OVERRIDE Allows BPF to override the execution of a probed function and set a different return value. This is used for error injection. -config FTRACE_MCOUNT_RECORD - def_bool y - depends on DYNAMIC_FTRACE - depends on HAVE_FTRACE_MCOUNT_RECORD - config FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY bool - depends on FTRACE_MCOUNT_RECORD + depends on DYNAMIC_FTRACE config FTRACE_MCOUNT_USE_CC def_bool y depends on $(cc-option,-mrecord-mcount) depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY - depends on FTRACE_MCOUNT_RECORD + depends on DYNAMIC_FTRACE config FTRACE_MCOUNT_USE_OBJTOOL def_bool y depends on HAVE_OBJTOOL_MCOUNT depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY depends on !FTRACE_MCOUNT_USE_CC - depends on FTRACE_MCOUNT_RECORD + depends on DYNAMIC_FTRACE select OBJTOOL config FTRACE_MCOUNT_USE_RECORDMCOUNT @@ -831,7 +821,7 @@ config FTRACE_MCOUNT_USE_RECORDMCOUNT depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY depends on !FTRACE_MCOUNT_USE_CC depends on !FTRACE_MCOUNT_USE_OBJTOOL - depends on FTRACE_MCOUNT_RECORD + depends on DYNAMIC_FTRACE config TRACING_MAP bool diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 4203fad56b6c..00b76d450a89 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -1042,10 +1042,6 @@ static struct ftrace_ops *removed_ops; */ static bool update_all_ops; -#ifndef CONFIG_FTRACE_MCOUNT_RECORD -# error Dynamic ftrace depends on MCOUNT_RECORD -#endif - struct ftrace_func_probe { struct ftrace_probe_ops *probe_ops; struct ftrace_ops ops; diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl index 0871b2e92584..861b56dda64e 100755 --- a/scripts/recordmcount.pl +++ b/scripts/recordmcount.pl @@ -359,7 +359,7 @@ if ($arch eq "x86_64") { $mcount_regex = "^\\s*([0-9a-fA-F]+):\\s*R_CKCORE_PCREL_JSR_IMM26BY2\\s+_mcount\$"; $alignment = 2; } else { - die "Arch $arch is not supported with CONFIG_FTRACE_MCOUNT_RECORD"; + die "Arch $arch is not supported with CONFIG_DYNAMIC_FTRACE"; } my $text_found = 0;
On Thu, 3 Jul 2025 15:49:16 -0400 Steven Rostedt <rostedt@goodmis.org> wrote: > diff --git a/include/linux/unwind_deferred.h b/include/linux/unwind_deferred.h > index 515d2995672d..14efd8c027aa 100644 > --- a/include/linux/unwind_deferred.h > +++ b/include/linux/unwind_deferred.h > @@ -28,8 +28,8 @@ void unwind_deferred_cancel(struct unwind_work *work); > > static __always_inline void unwind_reset_info(void) > { > - if (unlikely(current->unwind_info.id)) > - current->unwind_info.id = 0; > + if (unlikely(current->unwind_info.id.id)) > + current->unwind_info.id.id = 0; > /* > * As unwind_user_faultable() can be called directly and > * depends on nr_entries being cleared on exit to user, Bah, I did this while fixing the unwind patches. Oops! -- Steve
© 2016 - 2025 Red Hat, Inc.