From: Yonghong Song <yonghong.song@linux.dev>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>, bpf@vger.kernel.org
Cc: Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Eduard Zingerman <eddyz87@gmail.com>,
kernel-team@fb.com
Subject: Re: [PATCH bpf-next v3 10/11] bpf, x86: Give a kfunc's stack argument the 16-byte alignment it needs
Date: Fri, 16 Oct 2026 08:45:55 -0700 [thread overview]
Message-ID: <ace9e0d5-0357-4401-be7a-b77ddca86f0b@linux.dev> (raw)
In-Reply-To: <DM5X2Z5473A5.DNWH4JDJTYJF@gmail.com>
On 10/15/26 7:46 PM, Alexei Starovoitov wrote:
> On Tue, Oct 13, 2026 at 10:10 AM Yonghong Song <yonghong.song@linux.dev> wrote:
>> The JIT places a kfunc's stack arguments at the offsets from RSP that
>> the convention gives them, holes included, but RSP itself is only 8-byte
>> aligned in a BPF program, so a kfunc can get such an argument at an
>> address that is not 16-byte aligned.
> There are no kfuncs that take __int128 on the stack.
> The kernel is built with -mno-sse, so nothing but cmpxchg16b on &g
> cares about this alignment.
Indeed, with -mno-sse, the stack base whether it is 16-byte align or
not probably does not matter.
> Can we drop this patch?
> because...
>
>> + for (i = 0; i < n; i++)
>> + EMIT4(0xFF, 0x74, 0x24, disp); /* push qword ptr [rsp + disp] */
>> + skip[-1] = prog - skip;
> u64 kfunc(u64 a, u64 b, u64 c, u64 d, u64 e,
> __int128 x, __int128 y, __int128 z, u64 w)
> takes 133 bytes total. BPF_MAX_INSN_SIZE is 128.
> do_jit() prints "bpf_jit: fatal insn size error" and the prog
> fails to load. It was 92 bytes before this patch.
Yes, will drop this commit and the next self test which is to demonstrate
this commit.
>
> pw-bot: cr
next prev parent reply other threads:[~2026-10-16 15:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 17:09 [PATCH bpf-next v3 00/11] bpf: Follow up by-value struct and __int128 argument support Yonghong Song
2026-10-13 17:09 ` [PATCH bpf-next v3 01/11] bpf, x86: Pass a trampoline's stack arguments by the calling convention Yonghong Song
2026-10-13 17:09 ` [PATCH bpf-next v3 02/11] selftests/bpf: Test trampoline stack args in a program that can tail call Yonghong Song
2026-10-13 17:09 ` [PATCH bpf-next v3 03/11] selftests/bpf: Test by-value __int128 kfunc arguments at an odd slot Yonghong Song
2026-10-13 17:09 ` [PATCH bpf-next v3 04/11] bpf: Describe a BPF function to its trampoline as one u64 per slot Yonghong Song
2026-10-13 17:10 ` [PATCH bpf-next v3 05/11] bpf, x86: Place trampoline arguments by the x86-64 calling convention Yonghong Song
2026-10-13 17:10 ` [PATCH bpf-next v3 06/11] selftests/bpf: Test trampoline args around a 16-byte aligned stack arg Yonghong Song
2026-10-13 17:10 ` [PATCH bpf-next v3 07/11] selftests/bpf: Test trampoline args of a BPF function at an odd slot Yonghong Song
2026-10-13 17:10 ` [PATCH bpf-next v3 08/11] bpf: Refuse a trampoline on an unreliable static function with stack args Yonghong Song
2026-10-13 17:10 ` [PATCH bpf-next v3 09/11] selftests/bpf: Test trampolines on more BPF functions " Yonghong Song
2026-10-13 17:10 ` [PATCH bpf-next v3 10/11] bpf, x86: Give a kfunc's stack argument the 16-byte alignment it needs Yonghong Song
2026-10-16 2:46 ` Alexei Starovoitov
2026-10-16 15:45 ` Yonghong Song [this message]
2026-10-13 17:10 ` [PATCH bpf-next v3 11/11] selftests/bpf: Test that a kfunc gets its __int128 stack argument aligned Yonghong Song
2026-10-16 2:48 ` [PATCH bpf-next v3 00/11] bpf: Follow up by-value struct and __int128 argument support Alexei Starovoitov
2026-10-16 15:50 ` Yonghong Song
2026-10-16 16:00 ` Alexei Starovoitov
2026-10-16 16:22 ` Yonghong Song
2026-10-16 16:34 ` Alexei Starovoitov
2026-10-16 16:56 ` 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=ace9e0d5-0357-4401-be7a-b77ddca86f0b@linux.dev \
--to=yonghong.song@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@fb.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.