BPF List
 help / color / mirror / Atom feed
From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: <bot+bpf-ci@kernel.org>, <bpf@vger.kernel.org>
Cc: <ast@kernel.org>, <andrii@kernel.org>, <daniel@iogearbox.net>,
	<eddyz87@gmail.com>, <emil@etsalapatis.com>, <tj@kernel.org>,
	<kkd@meta.com>, <kernel-team@meta.com>, <martin.lau@kernel.org>,
	<yonghong.song@linux.dev>, <mason@kernel.org>,
	<ihor.solodrai@linux.dev>
Subject: Re: [PATCH bpf-next v1 12/18] bpf: Size the per-frame verifier structures for a 2 KiB stack
Date: Wed, 23 Sep 2026 22:27:32 +0200	[thread overview]
Message-ID: <DLMZ95N3740O.2NQLSZVH8NEQI@gmail.com> (raw)
In-Reply-To: <a1d67ea63858c1e4125d88f346df080360f4a9dd7b17e53163ccbfdb0dddd2c3@mail.kernel.org>

On Wed Sep 23, 2026 at 10:12 PM CEST, bot+bpf-ci wrote:
>> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>> index d8cafd3d74aa..11fa9f1f087c 100644
>> --- a/include/linux/bpf_verifier.h
>> +++ b/include/linux/bpf_verifier.h
>> @@ -19,11 +19,12 @@
>>   * that converting umax_value to int cannot overflow.
>>   */
>>  #define BPF_MAX_VAR_SIZ	(1 << 29)
>> -/* size of tmp_str_buf in bpf_verifier.
>> - * we need at least 306 bytes to fit full stack mask representation
>> - * (in the "-8,-16,...,-512" form)
>> +/*
>> + * size of tmp_str_buf in bpf_verifier.
>> + * we need at least 1399 bytes to fit full stack mask representation
>> + * (in the "-8,-16,...,-2048" form)
>>   */
>> -#define TMP_STR_BUF_LEN 320
>> +#define TMP_STR_BUF_LEN 1408
>
> TMP_STR_BUF_LEN is raised to 1408 so that bpf_fmt_stack_mask() can render
> all 256 slots. The commit message says the buffer grows "so that all 256
> slots still fit". But every place that consumes env->tmp_str_buf prints it
> through verbose() -> bpf_verifier_vlog(), which formats into a fixed kbuf:
>
> kernel/bpf/log.c:bpf_verifier_vlog() {
>     n = vscnprintf(log->kbuf, BPF_VERIFIER_TMP_LOG_SIZE, fmt, args);
> }
>
> BPF_VERIFIER_TMP_LOG_SIZE is still 1024 (include/linux/bpf_verifier.h).
> The precision backtracking log lines are:
>

I will bump the size.

> kernel/bpf/backtrack.c: {
>     verbose(env, "stack=%s before ", env->tmp_str_buf);
>     verbose(env, "stack=%s: ", env->tmp_str_buf);
> }
>
> With a full 256-slot mask, the "stack=%s before " line is 1412 bytes and is
> silently cut at 1023 characters. The remaining slots and the trailing
> " before " / ": " separator are lost, so the next log fragment runs into
> the truncated mask.
>
> The mask alone goes over the kbuf limit once roughly 168 or more slots are
> set. The larger tmp_str_buf therefore does not deliver the complete log
> line the comment and commit message promise. The extra 1 KiB only helps up
> to the 1023-character kbuf limit.
>
> This commit only resizes the structures; the verifier still caps the stack
> at 512 bytes here. The problem becomes reachable later in the same series,
> in d1a4a32c6444 ("bpf, x86: Allow programs 2 KiB of stack") and
> 5782325bd60a ("bpf, arm64: Allow programs 2 KiB of stack"), which let
> bpf_jit_supports_large_stack() programs use more than 64 slots. No later
> commit in 00a8442f56e5..7757cddf610a changes BPF_VERIFIER_TMP_LOG_SIZE or
> the print sites.
>
> The impact is limited to log readability (no memory-safety or
> verification-result impact), but selftests or tools that parse the stack=
> mask from level-2 logs will see incomplete data.
>
> Should BPF_VERIFIER_TMP_LOG_SIZE be raised to at least TMP_STR_BUF_LEN
> plus a small prefix, or should the mask be emitted in pieces with several
> verbose() calls?
>
>>  /* Patch buffer size */
>>  #define INSN_BUF_SIZE 32
>>
>> @@ -243,12 +244,13 @@ enum bpf_stack_slot_type {
>>  #define BPF_REG_SIZE 8	/* size of eBPF register in bytes */
>>
>>  /*
>> - * Largest number of BPF_REG_SIZE stack slots a single frame can have. A frame
>> - * may use any part of the MAX_BPF_STACK budget; check_max_stack_depth()
>> - * enforces the bound on the combined depth of frames sharing the kernel stack
>> - * and on each frame using a private stack.
>> + * Largest number of BPF_REG_SIZE stack slots a single frame can have, sized
>> + * for the largest stack budget any JIT supports. A frame may use any part of
>> + * its program's budget; check_max_stack_depth() enforces the budget on the
>> + * combined depth of frames sharing the kernel stack and on each frame using
>> + * a private stack.
>>   */
>> -#define MAX_BPF_STACK_SLOTS	(MAX_BPF_STACK / BPF_REG_SIZE)
>> +#define MAX_BPF_STACK_SLOTS	(MAX_BPF_STACK_JIT / BPF_REG_SIZE)
>
> [ ... ]
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/35909853278


  reply	other threads:[~2026-09-23 20:27 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23 19:11 [PATCH bpf-next v1 00/18] Raise BPF program stack size to 2KiB Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 01/18] bpf: Add accessors for verifier stack slots Kumar Kartikeya Dwivedi
2026-09-23 19:57   ` bot+bpf-ci
2026-09-23 20:04     ` Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 02/18] bpf: Widen the stack slot index in the jump history Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 03/18] bpf: Store linked registers in the jump history as an array Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 04/18] bpf: Track backtracking stack slots with bitmaps Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 05/18] bpf: Track scratched stack slots with a bitmap Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 06/18] bpf: Treat unknown-size stack reads as reaching the frame top Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 07/18] bpf: Size liveness stack masks by the stack each frame uses Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 08/18] bpf: Grow the verifier id scratch on demand Kumar Kartikeya Dwivedi
2026-09-23 19:24   ` sashiko-bot
2026-09-23 19:29     ` Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 09/18] selftests/bpf: Cover the tail call caller stack depth limit Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 10/18] selftests/bpf: Check that narrow stack stores define no slot Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 11/18] selftests/bpf: Check liveness merge of masks with different widths Kumar Kartikeya Dwivedi
2026-09-23 19:26   ` sashiko-bot
2026-09-23 19:29     ` Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 12/18] bpf: Size the per-frame verifier structures for a 2 KiB stack Kumar Kartikeya Dwivedi
2026-09-23 20:12   ` bot+bpf-ci
2026-09-23 20:27     ` Kumar Kartikeya Dwivedi [this message]
2026-09-23 22:55   ` Alexei Starovoitov
2026-09-23 19:11 ` [PATCH bpf-next v1 13/18] bpf: Bound program stack use by a per-program limit Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 14/18] selftests/bpf: Add load conditions on the program stack limit Kumar Kartikeya Dwivedi
2026-09-23 20:12   ` bot+bpf-ci
2026-09-23 20:27     ` Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 15/18] selftests/bpf: Give the 512-byte stack boundary tests a 2 KiB twin Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 16/18] bpf, x86: Allow programs 2 KiB of stack Kumar Kartikeya Dwivedi
2026-09-23 20:12   ` bot+bpf-ci
2026-09-23 20:28     ` Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 17/18] bpf, arm64: " Kumar Kartikeya Dwivedi
2026-09-23 19:11 ` [PATCH bpf-next v1 18/18] selftests/bpf: Test the 2 KiB stack budget Kumar Kartikeya Dwivedi
2026-09-23 20:12   ` bot+bpf-ci
2026-09-23 20:28     ` 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=DLMZ95N3740O.2NQLSZVH8NEQI@gmail.com \
    --to=memxor@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bot+bpf-ci@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=kernel-team@meta.com \
    --cc=kkd@meta.com \
    --cc=martin.lau@kernel.org \
    --cc=mason@kernel.org \
    --cc=tj@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox