On Sat, Jan 3, 2026 at 7:21 AM Alexei Starovoitov
[off-list ref] wrote:

On Wed, Dec 24, 2025 at 5:07 AM Menglong Dong [off-list ref] wrote:

quoted

Hi, all.

In this version, I did some modifications according to Andrii's
suggestion.

overall
-------
Sometimes, we need to hook both the entry and exit of a function with
TRACING. Therefore, we need define a FENTRY and a FEXIT for the target
function, which is not convenient.

Therefore, we add a tracing session support for TRACING. Generally
speaking, it's similar to kprobe session, which can hook both the entry
and exit of a function with a single BPF program.

We allow the usage of bpf_get_func_ret() to get the return value in the
fentry of the tracing session, as it will always get "0", which is safe
enough and is OK.

Session cookie is also supported with the kfunc bpf_fsession_cookie().
In order to limit the stack usage, we limit the maximum number of cookies
to 4.

kfunc design
------------
The kfunc bpf_fsession_is_return() and bpf_fsession_cookie() are
introduced, and they are both inlined in the verifier.

In current solution, we can't reuse the existing bpf_session_cookie() and
bpf_session_is_return(), as their prototype is different from
bpf_fsession_is_return() and bpf_fsession_cookie(). In
bpf_fsession_cookie(), we need the function argument "void *ctx" to get
the cookie. However, the prototype of bpf_session_cookie() is "void".

Maybe it's possible to reuse the existing bpf_session_cookie() and
bpf_session_is_return(). First, we move the nr_regs from stack to struct
bpf_tramp_run_ctx, as Andrii suggested before. Then, we define the session
cookies as flexible array in bpf_tramp_run_ctx like this:
    struct bpf_tramp_run_ctx {
        struct bpf_run_ctx run_ctx;
        u64 bpf_cookie;
        struct bpf_run_ctx *saved_run_ctx;
        u64 func_meta; /* nr_args, cookie_index, etc */
        u64 fsession_cookies[];
    };

The problem of this approach is that we can't inlined the bpf helper
anymore, such as get_func_arg, get_func_ret, get_func_arg_cnt, etc, as
we can't use the "current" in BPF assembly.

So maybe it's better to use the new kfunc for now? And I'm analyzing that
if it is possible to inline "current" in verifier. Maybe we can convert to
the solution above if it success.

I suspect your separate patch set to inline get_current addresses
 this concern?

Yeah. I'm hesitating if we should do it this way. I found that
even though we can inline the "current", which can be done by
using the "call bpf_get_current_task" in verifier, it's still hard to inline
the following function:

__bpf_kfunc void *bpf_fsession_cookie(void)
{
    ......
    return run_ctx->fsession_cookies[run_ctx->func_meta >> BPF_TRAMP_M_COOKIE];
}

We can only use the r0 register during the inline, and we
need at least another one register to finish the logic above. Do we
have a temporary register that can be used here?

I'm not sure if the effort is worth it, so I think maybe it's better
to keep the current approach. As for the inline of get_current,
it's an optimization that we can do anyway.

quoted

architecture
------------
The fsession stuff is arch related, so the -EOPNOTSUPP will be returned if
it is not supported yet by the arch. In this series, we only support
x86_64. And later, other arch will be implemented.

Changes since v4:

v5 looks to be in good shape. It needs a rebase now due to conflicts.

OK, I'll rebase and send it later.

Thanks!
Menglong Dong