| Message ID | 20250115-rcuref-ftrace-v1-1-76fa408c9884@cloudflare.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | ftrace: Allow tracing rcuref_*_slowpath | expand |
diff --git a/lib/Makefile b/lib/Makefile index a8155c972f02856fcc61ee949ddda436cfe211ff..1f5c9557c4cb5bf2b6e4ac7e87ed30bb3c8f4664 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -5,6 +5,10 @@ ccflags-remove-$(CONFIG_FUNCTION_TRACER) += $(CC_FLAGS_FTRACE) +ifdef CONFIG_FUNCTION_TRACER +CFLAGS_rcuref.o += $(CC_FLAGS_FTRACE) +endif + # These files are disabled because they produce lots of non-interesting and/or # flaky coverage that is not a function of syscall inputs. For example, # rbtree can be global and individual rotations don't correlate with inputs.
All objects under lib/ are built as non-traceable for performance reasons since commit 2464a609ded0 ("ftrace: do not trace library functions"): This prevents users not only from tracing library functions with ftrace but also from attaching kprobes to them: # perf probe -a rcuref_put_slowpath:32 [ 65.228593] trace_kprobe: Could not probe notrace function rcuref_put_slowpath The available solution is to rebuild the kernel with CONFIG_KPROBE_EVENTS_ON_NOTRACE=y. A usually disabled option because of its potential pitfalls, intended for those debugging ftrace itself. By default, in face of any bugs with reference counting, like the one we are currently tracking down [1], users cannot leverage kprobes to collect additional info like stack traces or data from the rcuref container, for example dst_entry. Building a debug kernel is the only option. Make it easier for users to troubleshoot reference counting issues by making the two rcuref_*_slowpath functions traceable. [1] https://lore.kernel.org/all/87ikxtfhky.fsf@cloudflare.com/ Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> --- lib/Makefile | 4 ++++ 1 file changed, 4 insertions(+)