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 14/18] selftests/bpf: Add load conditions on the program stack limit
Date: Wed, 23 Sep 2026 22:27:47 +0200	[thread overview]
Message-ID: <DLMZ9CDY11JH.OPHO5N2Z1OTQ@gmail.com> (raw)
In-Reply-To: <28a022f0799e2e49ed8bc3df23a3cefe6aa25ace227b4bd0e3fe35fd7d1a7f9b@mail.kernel.org>

On Wed Sep 23, 2026 at 10:12 PM CEST, bot+bpf-ci wrote:
>> diff --git a/tools/testing/selftests/bpf/progs/bpf_misc.h b/tools/testing/selftests/bpf/progs/bpf_misc.h
>> index 2ced1d751ace..f3dbc3b59bff 100644
>> --- a/tools/testing/selftests/bpf/progs/bpf_misc.h
>> +++ b/tools/testing/selftests/bpf/progs/bpf_misc.h
>> @@ -175,6 +175,9 @@
>>  #define __prepare_priv		__test_tag("test_prepare_priv")
>>  #define __load_if_JITed()	__test_tag("load_mode=jited")
>>  #define __load_if_no_JITed()	__test_tag("load_mode=no_jited")
>> +/* Whether programs may use more than 512 bytes of stack on this kernel and JIT */
>> +#define __load_if_large_stack()		__test_tag("stack_mode=large")
>> +#define __load_if_no_large_stack()	__test_tag("stack_mode=small")
>>  #define __stderr(msg)		__test_tag("test_expect_stderr=" msg)
>>  #define __stderr_unpriv(msg)	__test_tag("test_expect_stderr_unpriv=" msg)
>>  #define __stdout(msg)		__test_tag("test_expect_stdout=" msg)
>> diff --git a/tools/testing/selftests/bpf/test_loader.c b/tools/testing/selftests/bpf/test_loader.c
>> index a6e3fcc1079c..25eeb1c1248b 100644
>> --- a/tools/testing/selftests/bpf/test_loader.c
>> +++ b/tools/testing/selftests/bpf/test_loader.c
>
> [ ... ]
>
>> @@ -1331,6 +1349,7 @@ void run_subtest(struct test_loader *tester,
>>  {
>>  	struct test_subspec *subspec = unpriv ? &spec->unpriv : &spec->priv;
>>  	int current_runtime = is_jit_enabled() ? JITED : NO_JITED;
>> +	int current_stack = is_large_stack_supported() ? LARGE_STACK : SMALL_STACK;
>>  	struct bpf_program *tprog = NULL, *tprog_iter;
>>  	struct bpf_link *link, *links[32] = {};
>>  	struct test_spec *spec_iter;
>
> [ ... ]
>
>> @@ -1360,6 +1379,11 @@ void run_subtest(struct test_loader *tester,
>>  		return;
>>  	}
>>
>> +	if ((current_stack & spec->stack_mask) == 0) {
>> +		test__skip();
>> +		return;
>> +	}
>> +
>
> A subsystem pattern flags this as potentially concerning: the new
> stack-limit load condition skips the subtest with a bare test__skip() that
> prints no reason. When a user sees a verifier_large_stack or
> verifier_stack_ptr subtest reported as SKIP, they get no hint whether it
> was skipped because is_large_stack_supported() found the 2 KiB budget
> missing or present.
>
> This matters more because the probe can also fall back to "assuming 512
> bytes" when it fails for an unrelated reason. That fallback message goes to
> stderr before test__start_subtest_with_desc() runs, so it is not attached
> to the subtest that gets skipped.
>
> Does the skip need a message like the existing skip_reason and
> jited-disassembly skips in run_subtest do? Or is it acceptable for these
> stack-mode skips to match the arch_mask and load_mask pattern right above
> this check, which also skip without a message?
>

Won't fix.

>> diff --git a/tools/testing/selftests/bpf/testing_helpers.c b/tools/testing/selftests/bpf/testing_helpers.c
>> index d1d60451c5bc..47fe61a1ebff 100644
>> --- a/tools/testing/selftests/bpf/testing_helpers.c
>> +++ b/tools/testing/selftests/bpf/testing_helpers.c
>> @@ -517,6 +517,47 @@ bool is_jit_enabled(void)
>>  	return enabled;
>>  }
>>
>> +/*
>> + * Whether the kernel accepts a program using more than 512 bytes of stack,
>> + * which depends on the JIT in use. Probed once with a program that stores
>> + * at the 2 KiB depth. Only the verifier's verdict on that store is cached:
>> + * a load that fails for another reason, such as a missing capability, is
>> + * reported and probed again on the next call.
>> + */
>> +bool is_large_stack_supported(void)
>> +{
>> +	static int supported = -1;
>> +	struct bpf_insn insns[] = {
>> +		BPF_ST_MEM(BPF_DW, BPF_REG_10, -2048, 0),
>> +		BPF_MOV64_IMM(BPF_REG_0, 0),
>> +		BPF_EXIT_INSN(),
>> +	};
>> +	char log[1024] = {};
>> +	LIBBPF_OPTS(bpf_prog_load_opts, opts,
>> +		.log_buf = log,
>> +		.log_size = sizeof(log),
>> +		.log_level = 1,
>> +	);
>> +	int fd;
>> +
>> +	if (supported >= 0)
>> +		return supported;
>> +
>> +	fd = bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER, NULL, "GPL", insns, ARRAY_SIZE(insns),
>> +			   &opts);
>> +	if (fd >= 0) {
>> +		close(fd);
>> +		supported = 1;
>> +	} else if (strstr(log, "invalid write to stack")) {
>> +		supported = 0;
>> +	} else {
>> +		fprintf(stderr, "%s: probe failed with errno %d, assuming 512 bytes:\n%s",
>> +			__func__, errno, log);
>> +		return false;
>> +	}
>> +	return supported;
>> +}
>> +
>
> [ ... ]
>
>
> ---
> 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
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 [this message]
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=DLMZ9CDY11JH.OPHO5N2Z1OTQ@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