From: sashiko-bot@kernel.org
To: "Pu Lehui" <pulehui@huaweicloud.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v4 4/6] riscv, bpf: Add RV_TAILCALL_OFFSET macro to format tailcall offset
Date: Mon, 29 Jun 2026 14:10:34 +0000 [thread overview]
Message-ID: <20260629141034.D5F6F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260629140048.733346-5-pulehui@huaweicloud.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] The tail call offset macro `RV_TAILCALL_OFFSET` incorrectly double-counts the KCFI preamble when `CONFIG_CFI` is enabled, causing tail-called programs to skip their stack pointer adjustment and corrupt the caller's stack frame.
--
commit 655037e3f7e62935bb76d41ae8cffb13d2a38d50
Author: Pu Lehui <pulehui@huawei.com>
riscv, bpf: Add RV_TAILCALL_OFFSET macro to format tailcall offset
Add RV_TAILCALL_OFFSET macro to format tailcall offset, and correct the
relevant comments.
> diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
> index 69512d93ca4a7..c239696cca646 100644
> --- a/arch/riscv/net/bpf_jit_comp64.c
> +++ b/arch/riscv/net/bpf_jit_comp64.c
> @@ -21,6 +21,8 @@
> #define RV_KCFI_NINSNS (IS_ENABLED(CONFIG_CFI) ? 1 : 0)
> /* imm that allows emit_imm to emit max count insns */
> #define RV_MAX_COUNT_IMM 0x7FFF7FF7FF7FF7FF
> +/* kcfi, fentry and TCC init insns will be skipped on tailcall */
> +#define RV_TAILCALL_OFFSET ((RV_KCFI_NINSNS + RV_FENTRY_NINSNS + 1) * 4)
[Severity: Critical]
This is a pre-existing issue, but does RV_TAILCALL_OFFSET incorrectly
double-count the KCFI preamble when CONFIG_CFI is enabled?
Since prog->bpf_func already skips the 4-byte KCFI hash (because it points
to ctx->ro_insns + cfi_get_offset()), it looks like including RV_KCFI_NINSNS
here overshoots the correct jump target by 4 bytes.
Does this skip the necessary stack pointer adjustment instruction, causing
tail-called programs to execute prologue register saves using the unadjusted
stack pointer of the caller and potentially corrupting the kernel stack?
[ ... ]
> @@ -272,9 +274,7 @@ static void __build_epilogue(bool is_tail_call, struct rv_jit_context *ctx)
> if (!is_tail_call)
> emit_addiw(RV_REG_A0, RV_REG_A5, 0, ctx);
> emit_jalr(RV_REG_ZERO, is_tail_call ? RV_REG_T3 : RV_REG_RA,
> - /* kcfi, fentry and TCC init insns will be skipped on tailcall */
> - is_tail_call ? (RV_KCFI_NINSNS + RV_FENTRY_NINSNS + 1) * 4 : 0,
> - ctx);
> + is_tail_call ? RV_TAILCALL_OFFSET : 0, ctx);
> }
[ ... ]
> @@ -394,7 +394,7 @@ static int emit_bpf_tail_call(int insn, struct rv_jit_context *ctx)
> off = ninsns_rvoff(tc_ninsn - (ctx->ninsns - start_insn));
> emit_branch(BPF_JEQ, RV_REG_T2, RV_REG_ZERO, off, ctx);
>
> - /* goto *(prog->bpf_func + 4); */
> + /* goto *(prog->bpf_func + RV_TAILCALL_OFFSET); */
> off = offsetof(struct bpf_prog, bpf_func);
> if (is_12b_check(off, insn))
> return -1;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629140048.733346-1-pulehui@huaweicloud.com?part=4
next prev parent reply other threads:[~2026-06-29 14:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 14:00 [PATCH bpf-next v4 0/6] Mixing bpf2bpf and tailcalls for RV64 Pu Lehui
2026-06-29 14:00 ` Pu Lehui
2026-06-29 14:00 ` [PATCH bpf-next v4 1/6] bpf: Extract the is_struct_ops_tramp helper Pu Lehui
2026-06-29 14:00 ` Pu Lehui
2026-06-29 14:00 ` [PATCH bpf-next v4 2/6] riscv, bpf: Remove redundant ctx->offset initialization Pu Lehui
2026-06-29 14:00 ` Pu Lehui
2026-06-29 14:08 ` sashiko-bot
2026-07-06 7:18 ` Pu Lehui
2026-06-29 14:00 ` [PATCH bpf-next v4 3/6] riscv, bpf: Using kvzalloc_objs to allocate cache buffer Pu Lehui
2026-06-29 14:00 ` Pu Lehui
2026-06-29 14:00 ` [PATCH bpf-next v4 4/6] riscv, bpf: Add RV_TAILCALL_OFFSET macro to format tailcall offset Pu Lehui
2026-06-29 14:00 ` Pu Lehui
2026-06-29 14:10 ` sashiko-bot [this message]
2026-07-06 7:22 ` Pu Lehui
2026-06-29 14:00 ` [PATCH bpf-next v4 5/6] riscv, bpf: Mixing bpf2bpf and tailcalls Pu Lehui
2026-06-29 14:00 ` Pu Lehui
2026-06-29 14:06 ` sashiko-bot
2026-07-06 7:16 ` Pu Lehui
2026-06-29 14:00 ` [PATCH bpf-next v4 6/6] selftests/bpf: Remove tailcalls tests from DENYLIST.riscv64 Pu Lehui
2026-06-29 14:00 ` Pu Lehui
2026-06-29 16:19 ` bot+bpf-ci
2026-06-29 16:19 ` bot+bpf-ci
2026-07-06 7:23 ` Pu Lehui
2026-07-06 7:23 ` Pu Lehui
2026-06-29 14:21 ` [PATCH bpf-next v4 0/6] Mixing bpf2bpf and tailcalls for RV64 Björn Töpel
2026-06-29 14:21 ` Björn Töpel
2026-07-06 7:08 ` Pu Lehui
2026-07-06 7:08 ` Pu Lehui
2026-07-06 19:29 ` Eduard Zingerman
2026-07-06 19:29 ` Eduard Zingerman
2026-07-07 1:31 ` Pu Lehui
2026-07-07 1:31 ` Pu Lehui
2026-07-07 6:08 ` Björn Töpel
2026-07-07 6:08 ` Björn Töpel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260629141034.D5F6F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=pulehui@huaweicloud.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.