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

Hi, Andrii. After deeper analysis, I think the comment is explaining
why LSM doesn't need to check the return value type of the target
kernel function in this code patch, as the target for LSM always
return void or int. So I think the comment has nothing to do with
fsession or fexit, right?

Its position may cause some misunderstanding, and if it is placed
after "cast BPF_LSM_MAC", it maybe more clear. (But it's another thing,
and let's keep it still now)

Thanks!
Menglong Dong

quoted

[...]

quoted