On 2026/1/15 02:56 Andrii Nakryiko [off-list ref] write:

On Tue, Jan 13, 2026 at 6:11 PM Menglong Dong [off-list ref] wrote:

quoted

On 2026/1/14 09:22 Andrii Nakryiko [off-list ref] write:

quoted

On Sat, Jan 10, 2026 at 6:11 AM Menglong Dong [off-list ref] wrote:

quoted

The fsession is something that similar to kprobe session. It allow to
attach a single BPF program to both the entry and the exit of the target
functions.

[...]

quoted

quoted

--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c

@@ -6107,6 +6107,7 @@ static int btf_validate_prog_ctx_type(struct bpf_verifier_log *log, const struct
                case BPF_TRACE_FENTRY:
                case BPF_TRACE_FEXIT:
                case BPF_MODIFY_RETURN:
+               case BPF_TRACE_FSESSION:
                        /* allow u64* as ctx */
                        if (btf_is_int(t) && t->size == 8)
                                return 0;

@@ -6704,6 +6705,7 @@ bool btf_ctx_access(int off, int size, enum bpf_access_type type,
                        fallthrough;
                case BPF_LSM_CGROUP:
                case BPF_TRACE_FEXIT:
+               case BPF_TRACE_FSESSION:

According to the comment below we make this exception due to LSM.
FSESSION won't be using FSESSION programs, no? So this is not
necessary?

The comment describe the LSM case here, but the code
here is not only for LSM. It is also for FEXIT, which makes
sure that we can get the return value with "ctx[nr_args]".
So I think we still need it here, as we need to access the
return value with "ctx[nr_args]" too.

please update the comment then as well

ACK

quoted

quoted