On 2026/1/7 15:11 bot+bpf-ci@kernel.org write:

quoted

diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index a87304161d45..32c13175bc65 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c

@@ -3094,12 +3094,17 @@ static int emit_cond_near_jump(u8 **pprog, void *func, void *ip, u8 jmp_cond)
 static int invoke_bpf(const struct btf_func_model *m, u8 **pprog,
 		      struct bpf_tramp_links *tl, int stack_size,
 		      int run_ctx_off, bool save_ret,
-		      void *image, void *rw_image)
+		      void *image, void *rw_image, u64 func_meta)
 {
 	int i;
 	u8 *prog = *pprog;

 	for (i = 0; i < tl->nr_links; i++) {
+		if (tl->links[i]->link.prog->call_session_cookie) {
+			/* 'stack_size + 8' is the offset of func_md in stack */
+			emit_st_r0_imm64(&prog, func_meta, stack_size + 8);
+			func_meta -= (1 << BPF_TRAMP_M_COOKIE);
+		}

This decrement of func_meta is problematic for fsession programs. When
invoke_bpf() is called for fentry, func_meta gets decremented for each
program with call_session_cookie. Later, when invoke_bpf() is called
for fexit, it receives this already-decremented func_meta value.

Since fsession programs appear in both fentry and fexit lists (same
program object), call_session_cookie is true for both. The fexit part
will see a different cookie offset than the fentry part saw.

For example, with one fsession program:
  - fentry stores func_meta with cookie offset N, then decrements to N-1
  - fexit receives N-1, stores it, and the BPF program reads offset N-1

Should the func_meta offset be reset for fexit so that each fsession
program's fentry and fexit parts access the same cookie slot?

[ ... ]

quoted

@@ -3383,9 +3395,19 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im
 		}
 	}

+	if (bpf_fsession_cnt(tlinks)) {
+		/* clear all the session cookies' value */
+		for (int i = 0; i < cookie_cnt; i++)
+			emit_st_r0_imm64(&prog, 0, cookie_off - 8 * i);
+		/* clear the return value to make sure fentry always get 0 */
+		emit_st_r0_imm64(&prog, 0, 8);
+	}
+	func_meta = nr_regs + (((cookie_off - regs_off) / 8) << BPF_TRAMP_M_COOKIE);
+
 	if (fentry->nr_links) {
 		if (invoke_bpf(m, &prog, fentry, regs_off, run_ctx_off,
-			       flags & BPF_TRAMP_F_RET_FENTRY_RET, image, rw_image))
+			       flags & BPF_TRAMP_F_RET_FENTRY_RET, image, rw_image,
+			       func_meta))
 			return -EINVAL;
 	}

[ ... ]

quoted

@@ -3445,9 +3467,14 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im
 		}
 	}

+	/* set the "is_return" flag for fsession */
+	func_meta += (1 << BPF_TRAMP_M_IS_RETURN);
+	if (bpf_fsession_cnt(tlinks))
+		emit_st_r0_imm64(&prog, func_meta, nregs_off);
+
 	if (fexit->nr_links) {
 		if (invoke_bpf(m, &prog, fexit, regs_off, run_ctx_off,
-			       false, image, rw_image)) {
+			       false, image, rw_image, func_meta)) {

At this point func_meta has already been decremented during the fentry
invoke_bpf() call above. When invoke_bpf() processes the fexit list and
encounters an fsession program (which has call_session_cookie set since
it is the same program object), it will store this modified func_meta.

I think you misunderstand something. The "func_meta" that modified in
invoke_bpf() will not affect the value of "func_meta" here. We pass the value
of func_meta to invoke_bpf(), not the address.

This part should be OK, as it is covered by the selftests.

Thanks!
Menglong Dong

The cookie offset encoded in func_meta will be different from what the
fentry part stored, causing bpf_session_cookie() to return a pointer to
a different memory location for fexit than for fentry.

quoted

+			ret = -EINVAL;
+			goto cleanup;
+		}

---
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/20773233136