From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Yonghong Song" <yonghong.song@linux.dev>, <bpf@vger.kernel.org>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Jose E . Marchesi" <jose.marchesi@oracle.com>,
<kernel-team@fb.com>, "Martin KaFai Lau" <martin.lau@kernel.org>,
"Puranjay Mohan" <puranjay@kernel.org>
Subject: Re: [PATCH bpf-next 8/9] bpf: Introduce bpf register BPF_REG_PARAMS
Date: Tue, 21 Apr 2026 17:42:51 -0700 [thread overview]
Message-ID: <DHZ9M7ACK4GR.15DYRN8T1LZZ4@gmail.com> (raw)
In-Reply-To: <a98248e8-8b70-4125-b494-1a5ff12396fd@linux.dev>
On Tue Apr 21, 2026 at 5:09 PM PDT, Yonghong Song wrote:
>
>
> On 4/21/26 3:10 PM, Alexei Starovoitov wrote:
>> On Tue Apr 21, 2026 at 10:20 AM PDT, Yonghong Song wrote:
>>>
>>> /* Kernel hidden auxiliary/helper register. */
>>> -#define BPF_REG_AX MAX_BPF_REG
>>> -#define MAX_BPF_EXT_REG (MAX_BPF_REG + 1)
>>> +#define BPF_REG_PARAMS MAX_BPF_REG
>>> +#define BPF_REG_AX (MAX_BPF_REG + 1)
>>> +#define MAX_BPF_EXT_REG (MAX_BPF_REG + 2)
>> ...
>>
>>> --- a/tools/testing/selftests/bpf/progs/verifier_bpf_fastcall.c
>>> +++ b/tools/testing/selftests/bpf/progs/verifier_bpf_fastcall.c
>>> @@ -630,13 +630,13 @@ __xlated("...")
>>> __xlated("4: r0 = &(void __percpu *)(r0)")
>>> __xlated("...")
>>> /* may_goto expansion starts */
>>> -__xlated("6: r11 = *(u64 *)(r10 -24)")
>>> -__xlated("7: if r11 == 0x0 goto pc+6")
>>> -__xlated("8: r11 -= 1")
>>> -__xlated("9: if r11 != 0x0 goto pc+2")
>>> -__xlated("10: r11 = -24")
>>> +__xlated("6: r12 = *(u64 *)(r10 -24)")
>>> +__xlated("7: if r12 == 0x0 goto pc+6")
>>> +__xlated("8: r12 -= 1")
>>> +__xlated("9: if r12 != 0x0 goto pc+2")
>>> +__xlated("10: r12 = -24")
>> maybe shift it to r15 right away, so we don't need to touch this code
>> if/when true r12 is introduced?
>
> We can do this. Do you think the following is okay:
>
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index b77d0b06db6e..fe7b6b943ea4 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -59,9 +59,9 @@ struct ctl_table_header;
>
> /* Kernel hidden auxiliary/helper register. */
> #define BPF_REG_PARAMS MAX_BPF_REG
> -#define BPF_REG_AX (MAX_BPF_REG + 1)
> -#define MAX_BPF_EXT_REG (MAX_BPF_REG + 2)
> +#define MAX_BPF_EXT_REG (MAX_BPF_REG + 1)
> #define MAX_BPF_JIT_REG MAX_BPF_EXT_REG
> +#define BPF_REG_AX (MAX_BPF_REG + 4)
>
> /* unused opcode to mark special call to bpf_tail_call() helper */
> #define BPF_TAIL_CALL 0xf0
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index ae10b9ca018d..3ad286ef3085 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -1299,8 +1299,8 @@ static int bpf_jit_blind_insn(const struct bpf_insn *from,
> u32 imm_rnd = get_random_u32();
> s16 off;
>
> - BUILD_BUG_ON(BPF_REG_PARAMS + 2 != MAX_BPF_JIT_REG);
> - BUILD_BUG_ON(BPF_REG_AX + 1 != MAX_BPF_JIT_REG);
> + BUILD_BUG_ON(BPF_REG_PARAMS + 1 != MAX_BPF_JIT_REG);
> + BUILD_BUG_ON(BPF_REG_AX != MAX_BPF_JIT_REG + 3);
Ohh. We have:
static unsigned int PROG_NAME(stack_size)(const void *ctx, const struct bpf_insn *insn) \
{ \
u64 stack[stack_size / sizeof(u64)]; \
u64 regs[MAX_BPF_EXT_REG] = {}; \
Please double check that BPF_REG_AX is not used by the interpreter.
but it's starting to feel that my suggestion was premature.
Probably better to keep this patchset as-is.
next prev parent reply other threads:[~2026-04-22 0:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 17:19 [PATCH bpf-next 0/9] bpf: Prepare to support stack arguments Yonghong Song
2026-04-21 17:19 ` [PATCH bpf-next 1/9] bpf: Remove unused parameter from check_map_kptr_access() Yonghong Song
2026-04-21 17:19 ` [PATCH bpf-next 2/9] bpf: Fix tail_call_reachable leak Yonghong Song
2026-04-21 18:06 ` bot+bpf-ci
2026-04-22 0:29 ` Yonghong Song
2026-04-21 17:19 ` [PATCH bpf-next 3/9] bpf: Remove WARN_ON_ONCE in check_kfunc_mem_size_reg() Yonghong Song
2026-04-21 17:19 ` [PATCH bpf-next 4/9] bpf: Refactor to avoid redundant calculation of bpf_reg_state Yonghong Song
2026-04-21 21:40 ` Amery Hung
2026-04-21 23:42 ` Yonghong Song
2026-04-21 17:19 ` [PATCH bpf-next 5/9] bpf: Refactor to handle memory and size together Yonghong Song
2026-04-21 17:19 ` [PATCH bpf-next 6/9] bpf: Rename existing argno to arg Yonghong Song
2026-04-21 17:20 ` [PATCH bpf-next 7/9] bpf: Prepare verifier logs for upcoming kfunc stack arguments Yonghong Song
2026-04-21 22:07 ` Alexei Starovoitov
2026-04-21 23:56 ` Yonghong Song
2026-04-22 0:37 ` Alexei Starovoitov
2026-04-22 1:20 ` Yonghong Song
2026-04-22 1:52 ` Alexei Starovoitov
2026-04-21 17:20 ` [PATCH bpf-next 8/9] bpf: Introduce bpf register BPF_REG_PARAMS Yonghong Song
2026-04-21 22:10 ` Alexei Starovoitov
2026-04-22 0:09 ` Yonghong Song
2026-04-22 0:42 ` Alexei Starovoitov [this message]
2026-04-22 1:10 ` Yonghong Song
2026-04-21 17:20 ` [PATCH bpf-next 9/9] bpf: Reuse MAX_BPF_FUNC_ARGS for maximum number of arguments Yonghong Song
2026-04-21 17:52 ` bot+bpf-ci
2026-04-21 19:13 ` [PATCH bpf-next 0/9] bpf: Prepare to support stack arguments Kumar Kartikeya Dwivedi
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=DHZ9M7ACK4GR.15DYRN8T1LZZ4@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jose.marchesi@oracle.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=puranjay@kernel.org \
--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.