Re: [RFC PATCH bpf-next v1 0/3] bpf: Add BPF program type for overriding tracepoint probes

On 9/18/2025 4:47 PM, Jiri Olsa wrote:

[You don't often get email from olsajiri@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

On Thu, Sep 18, 2025 at 04:05:51PM +0800, Fuyu Zhao wrote:

quoted

On 9/18/2025 4:02 AM, Song Liu wrote:

quoted

On Wed, Sep 17, 2025 at 12:23 AM Fuyu Zhao [off-list ref] wrote:

quoted

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.

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.

IIUC, this work solves the same problem as raw tracepoint (raw_tp) or raw
tracepoint with btf (tp_btf).

Did I miss something?

Thanks,
Song

As I understand it, raw tracepoints (raw_tp) and raw tracepoint (raw_tp)
are designed mainly for tracing the kernel. The goal of this work is to
provide a way to override the tracepoint callback, so that kernel behavior
can be adjusted dynamically.

hi,
what's the use case for this? also I'd think you can do that just by
unregister the callback you want to override and register new one?

thanks,
jirka

At this moment, I don't have a real-world example. However, I mentioned one
possible use case in my reply to Steven:

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.

As for the reason not to unregister and register a new callback:
callbacks registered directly inside the kernel cannot be unregistered from
user space. From user space, we can only attach additional callbacks
with BPF programs, but can not remove or replace the ones already
registered in the kernel. Therefore, an override mechanism is needed.

Thanks,
Fuyu