public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	"Jose E . Marchesi" <jose.marchesi@oracle.com>,
	Kernel Team <kernel-team@fb.com>,
	Martin KaFai Lau <martin.lau@kernel.org>
Subject: Re: [PATCH bpf-next v6 04/17] bpf: Prepare verifier logs for upcoming kfunc stack arguments
Date: Tue, 21 Apr 2026 08:41:34 -0700	[thread overview]
Message-ID: <cba1d567-84db-4597-8e7a-a2203f1209d6@linux.dev> (raw)
In-Reply-To: <CAADnVQ+fb4mY4ermo5GBtz1jx7kB4xsDGE23m2G8qEQa261VNg@mail.gmail.com>



On 4/21/26 6:48 AM, Alexei Starovoitov wrote:
> On Mon, Apr 20, 2026 at 11:07 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>
>>
>> On 4/20/26 5:03 PM, Alexei Starovoitov wrote:
>>> On Sun Apr 19, 2026 at 9:33 AM PDT, Yonghong Song wrote:
>>>> This change prepares verifier log reporting for upcoming kfunc stack
>>>> argument support.
>>>>
>>>> Today verifier log code mostly assumes that an argument can be described
>>>> directly by a register number. That works for arguments passed in `R1`
>>>> to `R5`, but it does not work once kfunc arguments can also be
>>>> passed on the stack.
>>>>
>>>> Introduce an internal `argno` representation such that register-passed
>>>> arguments keep using their real register numbers, while stack-passed
>>>> arguments use an encoded value above a dedicated base.
>>>> `reg_arg_name()` converts this representation into either `R%d` or
>>>> `*(R11-off)` when emitting verifier logs. If a particular `argno`
>>>> is corresponding to a stack argument, print `*(R11-off)`. Otherwise,
>>>> print `R%d`. Here R11 presents the base of stack arguments.
>>>>
>>>> This keeps existing logs readable for register arguments and allows the
>>>> same log sites to handle future stack arguments without open-coding
>>>> special cases.
>>>>
>>>> Update selftests accordingly.
>>>>
>>>> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
>>>> ---
>>>>    include/linux/bpf_verifier.h                  |   1 +
>>>>    kernel/bpf/verifier.c                         | 649 ++++++++++--------
>>>>    .../testing/selftests/bpf/prog_tests/bpf_nf.c |  22 +-
>>>>    .../selftests/bpf/prog_tests/cb_refs.c        |   2 +-
>>>>    .../selftests/bpf/prog_tests/kfunc_call.c     |   2 +-
>>>>    .../selftests/bpf/prog_tests/linked_list.c    |   4 +-
>>>>    .../selftests/bpf/progs/cgrp_kfunc_failure.c  |  14 +-
>>>>    .../selftests/bpf/progs/cpumask_failure.c     |  10 +-
>>>>    .../testing/selftests/bpf/progs/dynptr_fail.c |  22 +-
>>>>    .../selftests/bpf/progs/file_reader_fail.c    |   4 +-
>>>>    tools/testing/selftests/bpf/progs/irq.c       |   4 +-
>>>>    tools/testing/selftests/bpf/progs/iters.c     |   6 +-
>>>>    .../selftests/bpf/progs/iters_state_safety.c  |  14 +-
>>>>    .../selftests/bpf/progs/iters_testmod.c       |   4 +-
>>>>    .../selftests/bpf/progs/iters_testmod_seq.c   |   4 +-
>>>>    .../selftests/bpf/progs/map_kptr_fail.c       |   2 +-
>>>>    .../selftests/bpf/progs/percpu_alloc_fail.c   |   4 +-
>>>>    .../testing/selftests/bpf/progs/rbtree_fail.c |   6 +-
>>>>    .../bpf/progs/refcounted_kptr_fail.c          |   2 +-
>>>>    .../testing/selftests/bpf/progs/stream_fail.c |   2 +-
>>>>    .../selftests/bpf/progs/task_kfunc_failure.c  |  18 +-
>>>>    .../selftests/bpf/progs/task_work_fail.c      |   6 +-
>>>>    .../selftests/bpf/progs/test_bpf_nf_fail.c    |   8 +-
>>>>    .../bpf/progs/test_kfunc_dynptr_param.c       |   2 +-
>>>>    .../bpf/progs/test_kfunc_param_nullable.c     |   2 +-
>>>>    .../selftests/bpf/progs/verifier_bits_iter.c  |   4 +-
>>>>    .../bpf/progs/verifier_ref_tracking.c         |   6 +-
>>>>    .../selftests/bpf/progs/verifier_vfs_reject.c |   8 +-
>>>>    .../testing/selftests/bpf/progs/wq_failures.c |   2 +-
>>>>    tools/testing/selftests/bpf/verifier/calls.c  |  14 +-
>>>>    30 files changed, 474 insertions(+), 374 deletions(-)
>>>>
>>>> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>>>> index b148f816f25b..9fbbddc40d21 100644
>>>> --- a/include/linux/bpf_verifier.h
>>>> +++ b/include/linux/bpf_verifier.h
>>>> @@ -913,6 +913,7 @@ struct bpf_verifier_env {
>>>>        * e.g., in reg_type_str() to generate reg_type string
>>>>        */
>>>>       char tmp_str_buf[TMP_STR_BUF_LEN];
>>>> +    char tmp_reg_arg_name_buf[32];
>>> the name is too long.
>>> Just tmp_arg_name ?
>>>
>>>>       struct bpf_insn insn_buf[INSN_BUF_SIZE];
>>>>       struct bpf_insn epilogue_buf[INSN_BUF_SIZE];
>>>>       struct bpf_scc_callchain callchain_buf;
>>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>>> index 3716d9688d00..6aa4dc161a56 100644
>>>> --- a/kernel/bpf/verifier.c
>>>> +++ b/kernel/bpf/verifier.c
>>>> @@ -1751,6 +1751,55 @@ static struct bpf_verifier_state *push_stack(struct bpf_verifier_env *env,
>>>>       return &elem->st;
>>>>    }
>>>>
>>>> +/*
>>>> + * Unified argument number encoding for verifier log messages.
>>>> + * Register args (arg_idx 0-4) use their register number (R1-R5).
>>>> + * Stack args (arg_idx 5+) are encoded as STACK_ARGNO_BASE + arg_idx
>>>> + * to avoid collision with register numbers. reg_arg_name() decodes
>>>> + * this back to a human-readable string like "*(R11-8)" for logs.
>>>> + */
>>>> +#define STACK_ARGNO_BASE 100
>>>> +
>>>> +static bool is_stack_argno(int argno)
>>>> +{
>>>> +    return argno >= STACK_ARGNO_BASE;
>>>> +}
>>>> +
>>>> +static u32 make_argno(u32 arg_idx)
>>>> +{
>>>> +    if (arg_idx < MAX_BPF_FUNC_REG_ARGS)
>>>> +            return BPF_REG_1 + arg_idx;
>>>> +    return STACK_ARGNO_BASE + arg_idx;
>>>> +}
>>>> +
>>>> +static u32 arg_idx_from_argno(int argno)
>>>> +{
>>>> +    if (is_stack_argno(argno))
>>>> +            return argno - STACK_ARGNO_BASE;
>>>> +    return argno - BPF_REG_1;
>>>> +}
>>>> +
>>>> +static int next_argno(int argno)
>>>> +{
>>>> +    return make_argno(arg_idx_from_argno(argno) + 1);
>>>> +}
>>> I don't like this +1, -1 dance all around. Makes the whole thing
>>> hard to follow.
>>> Keep argno starting at 1. So old regno == argno.
>> The above make_argno() returns an argno having regno == argno
>> for regno 1-5.
> No. It doesn't.
>
> it does:
>
> +static u32 make_argno(u32 arg_idx)
> +{
> +    if (arg_idx < MAX_BPF_FUNC_REG_ARGS)
> +            return BPF_REG_1 + arg_idx;
>
> so for argno == 0 it returns 1 and that's my objection.
> Make argno starting at 1.

Okay. Will do.



  reply	other threads:[~2026-04-21 15:41 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-19 16:33 [PATCH bpf-next v6 00/17] bpf: Support stack arguments for BPF functions and kfuncs Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 01/17] bpf: Remove unused parameter from check_map_kptr_access() Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 02/17] bpf: Refactor to avoid redundant calculation of bpf_reg_state Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 03/17] bpf: Refactor to handle memory and size together Yonghong Song
2026-04-20 23:58   ` Alexei Starovoitov
2026-04-21  4:04     ` Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 04/17] bpf: Prepare verifier logs for upcoming kfunc stack arguments Yonghong Song
2026-04-21  0:03   ` Alexei Starovoitov
2026-04-21  4:06     ` Yonghong Song
2026-04-21  6:07     ` Yonghong Song
2026-04-21 13:48       ` Alexei Starovoitov
2026-04-21 15:41         ` Yonghong Song [this message]
2026-04-21 15:46           ` Alexei Starovoitov
2026-04-21 16:37             ` Yonghong Song
2026-04-21 17:24             ` Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 05/17] bpf: Introduce bpf register BPF_REG_PARAMS Yonghong Song
2026-04-19 17:06   ` sashiko-bot
2026-04-19 18:14     ` Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 06/17] bpf: Reuse MAX_BPF_FUNC_ARGS for maximum number of arguments Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 07/17] bpf: Support stack arguments for bpf functions Yonghong Song
2026-04-19 19:15   ` sashiko-bot
2026-04-20  4:35     ` Yonghong Song
2026-04-21  0:37   ` Alexei Starovoitov
2026-04-21  4:15     ` Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 08/17] bpf: Reject stack arguments in non-JITed programs Yonghong Song
2026-04-19 18:21   ` sashiko-bot
2026-04-20  4:23     ` Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 09/17] bpf: Track r11 registers in const_fold and liveness Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 10/17] bpf: Prepare architecture JIT support for stack arguments Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 11/17] bpf: Enable r11 based insns Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 12/17] bpf: Support stack arguments for kfunc calls Yonghong Song
2026-04-19 17:08   ` sashiko-bot
2026-04-19 18:18     ` Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 13/17] bpf: Reject stack arguments if tail call reachable Yonghong Song
2026-04-19 17:08   ` sashiko-bot
2026-04-19 18:20     ` Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 14/17] bpf,x86: Implement JIT support for stack arguments Yonghong Song
2026-04-19 17:25   ` sashiko-bot
2026-04-19 18:55     ` Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 15/17] selftests/bpf: Add tests for BPF function " Yonghong Song
2026-04-19 17:15   ` sashiko-bot
2026-04-20  5:52     ` Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 16/17] selftests/bpf: Add tests for stack argument validation Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 17/17] selftests/bpf: Add verifier " Yonghong Song
2026-04-19 17:21   ` sashiko-bot
2026-04-20  6:14     ` Yonghong Song
2026-04-20 15:41 ` [PATCH bpf-next v6 00/17] bpf: Support stack arguments for BPF functions and kfuncs Puranjay Mohan
2026-04-20 20:22   ` Yonghong Song
2026-04-20 20:25     ` Puranjay Mohan
2026-04-20 21:49       ` Alexei Starovoitov
2026-04-20 23:44         ` Yonghong Song

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=cba1d567-84db-4597-8e7a-a2203f1209d6@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox