On 2026/1/10 22:42, bot+bpf-ci@kernel.org wrote:

quoted

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 2640ec2157e1..a416050e0dd2 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h

@@ -1231,6 +1231,7 @@ enum {

 #define BPF_TRAMP_M_NR_ARGS	0
 #define BPF_TRAMP_M_IS_RETURN	8
+#define BPF_TRAMP_M_COOKIE	9

[ ... ]

quoted

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 1b0292a03186..b91fd8af2393 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c

[ ... ]

quoted

@@ -22571,6 +22575,22 @@ static int fixup_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
 		insn_buf[1] = BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, BPF_TRAMP_M_IS_RETURN);
 		insn_buf[2] = BPF_ALU64_IMM(BPF_AND, BPF_REG_0, 1);
 		*cnt = 3;
+	} else if (desc->func_id == special_kfunc_list[KF_bpf_session_cookie] &&
+		   env->prog->expected_attach_type == BPF_TRACE_FSESSION) {
+		/* inline bpf_session_cookie() for fsession:
+		 *   __u64 *bpf_session_cookie(void *ctx)
+		 *   {
+		 *       u64 off = (((u64 *)ctx)[-1] >> BPF_TRAMP_M_COOKIE) & 0xFF;
+		 *       return &((u64 *)ctx)[-off];
+		 *   }
+		 */
+		insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
+		insn_buf[1] = BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, BPF_TRAMP_M_COOKIE);
+		insn_buf[2] = BPF_ALU64_IMM(BPF_AND, BPF_REG_0, 0xFF);
+		insn_buf[3] = BPF_ALU64_IMM(BPF_LSH, BPF_REG_0, 3);
+		insn_buf[4] = BPF_ALU64_REG(BPF_SUB, BPF_REG_0, BPF_REG_1);
+		insn_buf[5] = BPF_ALU64_IMM(BPF_NEG, BPF_REG_0, 0);

                        ^^^^^^^^

This inline code reads the cookie offset from (ctx[-1] >> 9) & 0xFF, but
does the x86 trampoline actually store the cookie offset at bit position 9?

Looking at arch/x86/net/bpf_jit_comp.c in __arch_prepare_bpf_trampoline(),
the trampoline stores nr_regs to the nregs_off location:

    emit_mov_imm64(&prog, BPF_REG_0, 0, (u32) nr_regs);
    emit_stx(&prog, BPF_DW, BPF_REG_FP, BPF_REG_0, -nregs_off);

This sets ctx[-1] to a small value like 0x0000000000000006, with the high
bits all zero. When the inline code executes:

    off = (ctx[-1] >> 9) & 0xFF  --> off = 0

The function then returns &ctx[-0] = ctx itself, which points to the
function arguments instead of the session cookie.

Is there a missing dependency on a later commit in the series? Commit
983968c39241 ("bpf,x86: add fsession support for x86_64") appears to add
the trampoline code that stores the cookie offset, but it comes after this
commit in the patch series.

This is intentionally. The whole feature is partly architecture specific.
In this patch, we implement the common part, and in the
983968c39241 ("bpf,x86: add fsession support for x86_64"), we
implement the feature for x86_64.

If the current architecture doesn't implement this feature, the
fsession will not be usable, so this inline code will not be called,
which make sense.

Thanks!
Menglong Dong

quoted

+		*cnt = 6;
+	}

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/20879693280