From: sashiko-bot@kernel.org
To: "Yonghong Song" <yonghong.song@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v4 12/25] bpf: Prepare architecture JIT support for stack arguments
Date: Fri, 15 May 2026 00:30:32 +0000 [thread overview]
Message-ID: <20260515003033.57358C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260513045054.2390945-1-yonghong.song@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Returning `-EFAULT` for an unsupported JIT feature causes a misleading syscall error.
--
commit 468549a72b25192a0a4df32e6475b6634931dde6
Author: Yonghong Song <yonghong.song@linux.dev>
bpf: Prepare architecture JIT support for stack arguments
This commit adds bpf_jit_supports_stack_args() to allow architectures to
indicate support for stack arguments. It rejects BPF functions with more
than 5 parameters at verification time if the architecture lacks this
support.
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index ec3fb8c8f4eef..3d8080eba5445 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
[ ... ]
> @@ -7886,8 +7886,14 @@ int btf_prepare_func_args(struct bpf_verifier_env *env, int subprog)
> MAX_BPF_FUNC_ARGS, tname, nargs);
> return -EFAULT;
> }
> - if (nargs > MAX_BPF_FUNC_REG_ARGS)
> + if (nargs > MAX_BPF_FUNC_REG_ARGS) {
> + if (!bpf_jit_supports_stack_args()) {
> + bpf_log(log, "JIT does not support function %s() with %d args\n",
> + tname, nargs);
> + return -EFAULT;
Does returning -EFAULT here cause a misleading error for userspace?
The function documentation states that -EFAULT is reserved for internal
verifier bugs to abort verification, while unsupported features or invalid
arguments typically return -EINVAL or -EOPNOTSUPP (which is used elsewhere
in this function for unsupported type tags).
Since returning -EFAULT propagates to the bpf() system call and typically
indicates a bad address, it might confuse userspace loaders like libbpf.
Would -EINVAL or -EOPNOTSUPP be more appropriate here?
> + }
> sub->stack_arg_cnt = nargs - MAX_BPF_FUNC_REG_ARGS;
> + }
>
> if (is_global && nargs > MAX_BPF_FUNC_REG_ARGS) {
> bpf_log(log, "global function %s has %d > %d args, stack args not supported\n",
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260513044949.2382019-1-yonghong.song@linux.dev?part=12
next prev parent reply other threads:[~2026-05-15 0:30 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 4:49 [PATCH bpf-next v4 00/25] bpf: Support stack arguments for BPF functions and kfuncs Yonghong Song
2026-05-13 4:49 ` [PATCH bpf-next v4 01/25] bpf: Convert bpf_get_spilled_reg macro to static inline function Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 02/25] bpf: Remove copy_register_state wrapper function Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 03/25] bpf: Add helper functions for r11-based stack argument insns Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 04/25] bpf: Set sub->arg_cnt earlier in btf_prepare_func_args() Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 05/25] bpf: Support stack arguments for bpf functions Yonghong Song
2026-05-14 10:46 ` sashiko-bot
2026-05-14 16:07 ` Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 06/25] bpf: Refactor jmp history to use dedicated spi/frame fields Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 07/25] bpf: Add precision marking and backtracking for stack argument slots Yonghong Song
2026-05-13 5:44 ` bot+bpf-ci
2026-05-13 4:50 ` [PATCH bpf-next v4 08/25] bpf: Refactor record_call_access() to extract per-arg logic Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 09/25] bpf: Use arg_is_fp() in has_fp_args() Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 10/25] bpf: Extend liveness analysis to track stack argument slots Yonghong Song
2026-05-13 5:44 ` bot+bpf-ci
2026-05-14 22:53 ` sashiko-bot
2026-05-13 4:50 ` [PATCH bpf-next v4 11/25] bpf: Reject stack arguments in non-JITed programs Yonghong Song
2026-05-13 5:33 ` bot+bpf-ci
2026-05-14 23:59 ` sashiko-bot
2026-05-13 4:50 ` [PATCH bpf-next v4 12/25] bpf: Prepare architecture JIT support for stack arguments Yonghong Song
2026-05-13 5:33 ` bot+bpf-ci
2026-05-15 0:30 ` sashiko-bot [this message]
2026-05-13 4:50 ` [PATCH bpf-next v4 13/25] bpf: Enable r11 based insns Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 14/25] bpf: Support stack arguments for kfunc calls Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 15/25] bpf: Reject stack arguments if tail call reachable Yonghong Song
2026-05-13 5:33 ` bot+bpf-ci
2026-05-15 3:23 ` sashiko-bot
2026-05-13 4:51 ` [PATCH bpf-next v4 16/25] bpf: Disable private stack for x86_64 if stack arguments used Yonghong Song
2026-05-13 5:33 ` bot+bpf-ci
2026-05-13 4:51 ` [PATCH bpf-next v4 17/25] bpf,x86: Implement JIT support for stack arguments Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 18/25] selftests/bpf: Add tests for BPF function " Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 19/25] selftests/bpf: Add tests for stack argument validation Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 20/25] selftests/bpf: Add BTF fixup for __naked subprog parameter names Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 21/25] selftests/bpf: Add verifier tests for stack argument validation Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 22/25] selftests/bpf: Add precision backtracking test for stack arguments Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 23/25] bpf, arm64: Map BPF_REG_0 to x8 instead of x7 Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 24/25] bpf, arm64: Add JIT support for stack arguments Yonghong Song
2026-05-13 4:52 ` [PATCH bpf-next v4 25/25] selftests/bpf: Enable stack argument tests for arm64 Yonghong Song
2026-05-13 16:33 ` [PATCH bpf-next v4 00/25] bpf: Support stack arguments for BPF functions and kfuncs Alexei Starovoitov
2026-05-13 17:41 ` Yonghong Song
2026-05-13 17:51 ` Alexei Starovoitov
2026-05-13 18:11 ` Yonghong Song
2026-05-13 16:40 ` patchwork-bot+netdevbpf
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=20260515003033.57358C2BCB3@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yonghong.song@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.