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>,
Catalin Marinas <catalin.marinas@arm.com>,
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>,
Puranjay Mohan <puranjay@kernel.org>,
Will Deacon <will@kernel.org>,
Xu Kuohai <xukuohai@huaweicloud.com>
Subject: Re: [PATCH bpf-next v7 08/24] bpf: Support stack arguments for bpf functions
Date: Mon, 20 Apr 2026 21:18:33 -0700 [thread overview]
Message-ID: <2a2ae6a9-7b0d-4baf-88ee-4b6896734acf@linux.dev> (raw)
In-Reply-To: <CAADnVQ+vD_06Xs2_=7S4scvv+9_STZVgWtTKTrHRbRJB04OkaA@mail.gmail.com>
On 4/20/26 8:51 PM, Alexei Starovoitov wrote:
> On Mon, Apr 20, 2026 at 8:36 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>> Currently BPF functions (subprogs) are limited to 5 register arguments.
>> With [1], the compiler can emit code that passes additional arguments
>> via a dedicated stack area through bpf register BPF_REG_PARAMS (r11),
>> introduced in the previous patch.
>>
>> The compiler uses positive r11 offsets for incoming (callee-side) args
>> and negative r11 offsets for outgoing (caller-side) args, following the
>> x86_64/arm64 calling convention direction. There is an 8-byte gap at
>> offset 0 separating the two regions:
>> Incoming (callee reads): r11+8 (arg6), r11+16 (arg7), ...
>> Outgoing (caller writes): r11-8 (arg6), r11-16 (arg7), ...
>>
>> The following is an example to show how stack arguments are saved
>> and transferred between caller and callee:
>>
>> int foo(int a1, int a2, int a3, int a4, int a5, int a6, int a7) {
>> ...
>> bar(a1, a2, a3, a4, a5, a6, a7, a8);
>> ...
>> }
>>
>> Caller (foo) Callee (bar)
>> ============ ============
>> Incoming (positive offsets): Incoming (positive offsets):
>>
>> r11+8: [incoming arg 6] r11+8: [incoming arg 6] <-+
>> r11+16: [incoming arg 7] r11+16: [incoming arg 7] <-|+
>> r11+24: [incoming arg 8] <-||+
>> Outgoing (negative offsets): |||
>> r11-8: [outgoing arg 6 to bar] -------->-------------------------+||
>> r11-16: [outgoing arg 7 to bar] -------->--------------------------+|
>> r11-24: [outgoing arg 8 to bar] -------->---------------------------+
>>
>> If the bpf function has more than one call:
>>
>> int foo(int a1, int a2, int a3, int a4, int a5, int a6, int a7) {
>> ...
>> bar1(a1, a2, a3, a4, a5, a6, a7, a8);
>> ...
>> bar2(a1, a2, a3, a4, a5, a6, a7, a8, a9);
>> ...
>> }
>>
>> Caller (foo) Callee (bar2)
>> ============ ==============
>> Incoming (positive offsets): Incoming (positive offsets):
>>
>> r11+8: [incoming arg 6] r11+8: [incoming arg 6] <+
>> r11+16: [incoming arg 7] r11+16: [incoming arg 7] <|+
>> r11+24: [incoming arg 8] <||+
>> Outgoing for bar2 (negative offsets): r11+32: [incoming arg 9] <|||+
>> r11-8: [outgoing arg 6] ---->----------->-------------------------+|||
>> r11-16: [outgoing arg 7] ---->----------->--------------------------+||
>> r11-24: [outgoing arg 8] ---->----------->---------------------------+|
>> r11-32: [outgoing arg 9] ---->----------->----------------------------+
>>
>> The verifier tracks stack arguments separately from the regular r10
>> stack. The stack_arg_regs are stored in bpf_func_state. This separation
>> keeps the stack arg area from interfering with the normal stack and
>> frame pointer (r10) bookkeeping. Similar to stacksafe(), introduce
>> stack_arg_safe() to do pruning check.
>>
>> A per-state bitmask out_stack_arg_mask tracks which outgoing stack arg
>> slots have been written on the current path. Each bit corresponds to
>> an outgoing slot index (bit 0 = r11-8 = arg6, bit 1 = r11-16 = arg7,
>> etc.). At a call site, the verifier checks that all slots required by
>> the callee have their corresponding mask bits set. This enables
>> precise per-path tracking: if one branch of a conditional writes arg6
>> but another does not, the mask correctly reflects the difference and
>> the verifier rejects the uninitialized path. The mask is included in
>> stack_arg_safe() so that states with different sets of initialized
>> slots are not incorrectly pruned together.
> you didn't address my comments.
After sending out v7, I then found you have some comments for v6. I will
address all issues in the next revision.
>
> pw-bot: cr
>
prev parent reply other threads:[~2026-04-21 4:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260421033252.575374-1-yonghong.song@linux.dev>
[not found] ` <20260421033333.580534-1-yonghong.song@linux.dev>
2026-04-21 3:51 ` [PATCH bpf-next v7 08/24] bpf: Support stack arguments for bpf functions Alexei Starovoitov
2026-04-21 4:18 ` Yonghong Song [this message]
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=2a2ae6a9-7b0d-4baf-88ee-4b6896734acf@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=catalin.marinas@arm.com \
--cc=daniel@iogearbox.net \
--cc=jose.marchesi@oracle.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=puranjay@kernel.org \
--cc=will@kernel.org \
--cc=xukuohai@huaweicloud.com \
/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.