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

[Fuyu Zhao <zhaofuyu@vivo.com>]

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:
>>
>>
>> On 9/18/2025 4:02 AM, Song Liu wrote:
>>> On Wed, Sep 17, 2025 at 12:23 AM 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.
>>>>
>>>> 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