public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Puranjay Mohan <puranjay@kernel.org>, 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 <puranjay12@gmail.com>
Subject: Re: [PATCH bpf-next v6 00/17] bpf: Support stack arguments for BPF functions and kfuncs
Date: Mon, 20 Apr 2026 13:22:39 -0700	[thread overview]
Message-ID: <21aad67d-97b8-4ffd-8b4a-747ee8b917be@linux.dev> (raw)
In-Reply-To: <m2mryx1vwi.fsf@kernel.org>



On 4/20/26 8:41 AM, Puranjay Mohan wrote:
> Yonghong Song <yonghong.song@linux.dev> writes:
>
>> Currently, bpf function calls and kfunc's are limited by 5 reg-level
>> parameters. For function calls with more than 5 parameters,
>> developers can use always inlining or pass a struct pointer
>> after packing more parameters in that struct although it may have
>> some inconvenience. But there is no workaround for kfunc if more
>> than 5 parameters is needed.
>>
>> This patch set lifts the 5-argument limit by introducing stack-based
>> argument passing for BPF functions and kfunc's, coordinated with
>> compiler support in LLVM [1]. The compiler emits loads/stores through
>> a new bpf register r11 (BPF_REG_PARAMS) to pass arguments beyond
>> the 5th, keeping the stack arg area separate from the r10-based program
>> stack. The current maximum number of arguments is capped at
>> MAX_BPF_FUNC_ARGS (12), which is sufficient for the vast majority of
>> use cases.
>>
>> All kfunc/bpf-function arguments are caller saved, including stack
>> arguments. For register arguments (r1-r5), the verifier already marks
>> them as clobbered after each call. For stack arguments, the verifier
>> invalidates all outgoing stack arg slots immediately after a call,
>> requiring the compiler to re-store them before any subsequent call.
>> This follows the native calling convention where all function
>> parameters are caller saved.
>>
>> The x86_64 JIT translates r11-relative accesses to RBP-relative
>> native instructions. Each function's stack allocation is extended
>> by 'max_outgoing' bytes to hold the outgoing arg area below the
>> callee-saved registers. This makes implementation easier as the r10
>> can be reused for stack argument access. At both BPF-to-BPF and kfunc
>> calls, outgoing args are pushed onto the expected calling convention
>> locations directly. The incoming parameters can directly get the value
>> from caller.
>>
>> To support kfunc stack arguments, before doing any stack arguments,
>> existing codes are refactored/modified to use bpf_reg_state as much
>> as possible instead of using regno, and to pass a non-negative argno,
>> encoded to support both registers and stack arguments, as a single
>> variable.
>>
>> Global subprogs with >5 args are not yet supported. Only x86_64
>> is supported for now.
>>
>> For the rest of patches, patches 1-4 make changes to make it
>> easy for future stack arguments for kfuncs. Patches 5-8
>> supports bpf-to-bpf stack arguments. Patch 9 rejects interpreter
>> for stack arguments. Patch 10 rejects subprogs if tailcall reachable.
>> Patch 11 adds stack argument support for kfuncs. Patch 12 enables
>> stack arguments for x86_64 and Patch 13 implements the x86_64 JIT.
>> Patches 14-16 are some test cases.
>>
>>    [1] https://github.com/llvm/llvm-project/pull/189060
>>
>> Note:
>>    - The patch set is on top of the following commit:
>>      eb0d6d97c27c  Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
>>    - This patch set requires latest llvm23 compiler. It is possible that a build
>>      failure may appear:
>>        /home/yhs/work/bpf-next/scripts/mod/modpost.c:59:13: error: variable 'extra_warn' set but not used [-Werror,-Wunused-but-set-global]
>>               59 | static bool extra_warn;
>>                  |             ^
>>            1 error generated.
>>      In this case, the following hack can workaround the build issue:
>>        --- a/Makefile
>>        +++ b/Makefile
>>        @@ -467,7 +467,7 @@ KERNELDOC       = $(srctree)/tools/docs/kernel-doc
>>         export KERNELDOC
>>
>>         KBUILD_USERHOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
>>        -                        -O2 -fomit-frame-pointer -std=gnu11
>>        +                        -O2 -fomit-frame-pointer -std=gnu11 -Wno-unused-but-set-global
>>         KBUILD_USERCFLAGS  := $(KBUILD_USERHOSTCFLAGS) $(USERCFLAGS)
>>         KBUILD_USERLDFLAGS := $(USERLDFLAGS)
>>
>> Changelogs:
>>    v5 -> v6:
>>      - v5: https://lore.kernel.org/bpf/20260417034658.2625353-1-yonghong.song@linux.dev/
>>      - Do stack arguments invalidation after bpf function or kfunc all. This is to
>>        following native achitecture calling convention.
>>      - Fix some r11 related issues in const_fold, liveness and insn checking.
>>      - Fix a few places for precision marking for stack arguments. All these cases
>>        have const value and mark them as precise.
>>      - Unconditionally copy some incoming/outgoing stat.
>>      - Fix a missing tailcall case with main prog having tailcall and there is no
>>        other subprog's.
>>      - Add and fix tests as suggested in v5.
>>      - Reorder some patches, e.g., preparing stack arguments in bpf functions,
>>        disabling JIT, before allowing proper r11 usage.
>>    v4 -> v5:
>>      - v4: https://lore.kernel.org/bpf/20260412045826.254200-1-yonghong.song@linux.dev/
>>      - Use r11 instead of r12, llvm also updated with r11.
>>      - Change int type 'reg_or_arg' to u32 'argno' where 'argno' encodes to support
>>        both bpf registers and stack arguments.
>>      - Track per-state bitmask 'out_stack_arg_mask' for r11 based stores, so at any
>>        particular call, it knows what stores are available. This is important since
>>        stores may be in different basic block.
>>      - Previously after each call, all store slots are invalidated. This patches
>>        disabled such invalidation.
>>      - Ensure r11 reg only appearing in allowed insns. Also avoid r11 for reg tracking
>>        purpose.
>>      - Make stack_arg_regs more similar to regular reg's (struct bpf_reg_state *)..
>>      - Reorder r11 based stores from 'arg6:off:-24, arg7:off:-16, arg8:off:-8" to
>>        "arg6:off:-8, arg7:off:-16, arg8:off:-24".
>>      - Add a few more tests, including e.g., two callee's with different number of
>>        stack arguments, shared r11-stores in different branches, etc.
>>
>>    v3 -> v4:
>>      - v3: https://lore.kernel.org/bpf/20260405172505.1329392-1-yonghong.song@linux.dev/
>>      - Refactor/Modify codes to make it easier for later kfunc stack argument support
>>      - Invalidate outgoing slots immediately after the call to prevent reuse
>>      - Fix interaction between stack argument PTR_TO_STACK and dead slot poisoning
>>      - Reject stack arguments if tail call reachable
>>      - Disable private stack if stack argument is used
>>      - Allocate outgoing stack argument region after callee saved registers, and this
>>        simplifies the JITed code a lot.
>>    v2 -> v3:
>>      - v2: https://lore.kernel.org/bpf/20260405165300.826241-1-yonghong.song@linux.dev/
>>      - Fix selftest stack_arg_gap_at_minus8().
>>      - Fix a few 'UTF-8' issues.
>>    v1 -> v2:
>>      - v1: https://lore.kernel.org/bpf/20260402012727.3916819-1-yonghong.song@linux.dev/
>>      - Add stack_arg_safe() to do pruning for stack arguments.
>>      - Fix an issue with KF_ARG_PTR_TO_MEM_SIZE. Since a faked register is
>>        used, added verification log to indicate the start and end of such
>>        faked register usage.
>>      - For x86_64 JIT, copying incoming parameter values directly from caller's stack.
>>      - Add test cases with stack arguments e.g. mem, mem+size, dynptr, iter, etc.
>>
>> Yonghong Song (17):
>>    bpf: Remove unused parameter from check_map_kptr_access()
>>    bpf: Refactor to avoid redundant calculation of bpf_reg_state
>>    bpf: Refactor to handle memory and size together
>>    bpf: Prepare verifier logs for upcoming kfunc stack arguments
>>    bpf: Introduce bpf register BPF_REG_PARAMS
>>    bpf: Reuse MAX_BPF_FUNC_ARGS for maximum number of arguments
>>    bpf: Support stack arguments for bpf functions
>>    bpf: Reject stack arguments in non-JITed programs
>>    bpf: Track r11 registers in const_fold and liveness
>>    bpf: Prepare architecture JIT support for stack arguments
>>    bpf: Enable r11 based insns
>>    bpf: Support stack arguments for kfunc calls
>>    bpf: Reject stack arguments if tail call reachable
>>    bpf,x86: Implement JIT support for stack arguments
>>    selftests/bpf: Add tests for BPF function stack arguments
>>    selftests/bpf: Add tests for stack argument validation
>>    selftests/bpf: Add verifier tests for stack argument validation
>>
> This set looks good to me overall:
>
> Acked-by: Puranjay Mohan <puranjay@kernel.org>
>
> I added support for arm64 in https://lore.kernel.org/all/20260420153603.4097618-1-puranjay@kernel.org/
> Please incorporate it into your series if you do another version.

Thanks, Puranjay! I will send another revision later which adds support
for precision backtracking and additional/modified test cases among other
things. I won't include your patches in the next revision. Once the patch
set is stable enough, I can add your patches. Optionally, the patch set is
already large enough, so maybe at some point, after this patch set is merged,
you can send your patch set separately.

>
> Thanks,
> Puranjay


  reply	other threads:[~2026-04-20 20:23 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
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 [this message]
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=21aad67d-97b8-4ffd-8b4a-747ee8b917be@linux.dev \
    --to=yonghong.song@linux.dev \
    --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=puranjay12@gmail.com \
    --cc=puranjay@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