Sorry, I just realized that I forgot to include the CC list in my first reply. Resending with CCs. Apologies to Steven for the extra noise.
On 9/18/2025 3:30 AM, Steven Rostedt wrote:
On Wed, 17 Sep 2025 15:22:39 +0800 Fuyu Zhao zhaofuyu@vivo.com wrote:
Hi everyone,
This patchset introduces a new BPF program type that allows overriding a tracepoint probe function registered via register_trace_*.
Motivation
Tracepoint probe functions registered via register_trace_* in the kernel cannot be dynamically modified, changing a probe function requires recompiling the kernel and rebooting. Nor can BPF programs change an existing probe function.
I'm confused by what you mean by "tracepoint probe function"?
You mean the function callback that gets called via the "register_trace_*()"?
Yes, that’s correct. My earlier wording was not very precise — thanks for pointing that out.
Overiding tracepoint supports a way to apply patches into kernel quickly (such as applying security ones), through predefined static tracepoints, without waiting for upstream integration.
This sounds way out of scope for tracepoints. Please provide a solid example for this.
I appreciate your comment. The example I gave about security patches probably wasn’t a good one here — I just meant to show the idea of changing kernel behavior at runtime. Sorry for the confusion.
At the moment, I don’t have a solid real-world example to provide. This work is still in an exploratory stage.
One possible use case is CPU core selection under certain scenarios. For example, developers may want to experiment with alternative strategies for deciding which CPU a task should run on to improve performance.
If a tracepoint is added as a hook point in this path, then overriding its function callback could make it possible to dynamically adjust the cpu-selection logic without rebuilding and rebooting the kernel.
The same mechanism could also be applied in other kernel paths where developers want to make quick changes from user space.
This patchset demonstrates the way to override probe functions by BPF program.
Overview
This patchset adds BPF_PROG_TYPE_RAW_TRACEPOINT_OVERRIDE program type. When this type of BPF program attaches, it overrides the target tracepoint probe function.
And it also extends a new struct type "tracepoint_func_snapshot", which extends the tracepoint structure. It is used to record the original probe function registered by kernel after BPF program being attached and restore from it after detachment.
The tracepoint structure exists for every tracepoint in the kernel. By adding a pointer to it, you just increased the size of the tracepoint. I'm already complaining that each tracepoint causes around 5K of memory overhead, and I'd like to make it smaller.
-- Steve
It is true that adding a pointer to the tracepoint structure increases memory overhead. However, memory for "snapshot" pointer will only be allocated after a BPF program is attached, and freed once it is dettached.
I am also considering whether it is possible to reuse existing structures to reduce memory usage.
I'd be very grateful for any suggestions or guidance you might have.
Thanks, Fuyu