From: "Emil Tsalapatis" <emil@etsalapatis.com>
To: "zhidao su" <soolaugust@gmail.com>, <tj@kernel.org>,
<void@manifault.com>, <arighi@nvidia.com>, <changwoo@igalia.com>
Cc: <sched-ext@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<suzhidao@xiaomi.com>
Subject: Re: [PATCH] tools/sched_ext: Improve BPF verifier arena detection workaround
Date: Mon, 02 Feb 2026 22:54:40 -0500 [thread overview]
Message-ID: <DG50UKIT01F0.13MHQV8KYVF0D@etsalapatis.com> (raw)
In-Reply-To: <20260203031954.915681-1-suzhidao@xiaomi.com>
On Mon Feb 2, 2026 at 10:19 PM EST, zhidao su wrote:
> Replace the BPF verifier workaround in scx_sdt scheduler with a more
> elegant solution that:
>
> 1. Uses volatile cast instead of bpf_printk to generate LD.IMM instruction
> without producing unnecessary output
> 2. Adds conditional compilation based on __BPF_FEATURE_ADDR_SPACE_CAST
> to eliminate the workaround entirely on modern toolchains
> 3. Updates documentation to reflect broader compatibility concerns
>
> This eliminates the side effects of the previous hack while maintaining
> compatibility across different kernel/BPF toolchain versions.
>
This code change is a bit of a non-sequitur (BPF_FEATURE_ADDR_SPACE_CAST
is unrelated to the problem scx_arena_subprog_init solves) and causes
the scheduler to fail to load for me. Could you please explain the logic behind
this patch? Does it work on your machine and if so could you let me know what
toolchain and kernel you're using?
> Signed-off-by: zhidao su <suzhidao@xiaomi.com>
> ---
> tools/sched_ext/scx_sdt.bpf.c | 24 +++++++++++++++---------
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/tools/sched_ext/scx_sdt.bpf.c b/tools/sched_ext/scx_sdt.bpf.c
> index 31b09958e8d5..88ac3043a643 100644
> --- a/tools/sched_ext/scx_sdt.bpf.c
> +++ b/tools/sched_ext/scx_sdt.bpf.c
> @@ -64,15 +64,15 @@ DEFINE_SDT_STAT(select_busy_cpu);
> static __u64 zero = 0;
>
> /*
> - * XXX Hack to get the verifier to find the arena for sdt_exit_task.
> - * As of 6.12-rc5, The verifier associates arenas with programs by
> - * checking LD.IMM instruction operands for an arena and populating
> - * the program state with the first instance it finds. This requires
> - * accessing our global arena variable, but scx methods do not necessarily
> - * do so while still using pointers from that arena. Insert a bpf_printk
> - * statement that triggers at most once to generate an LD.IMM instruction
> - * to access the arena and help the verifier.
> + * Helper to ensure BPF verifier can track arena usage.
> + * On older toolchains, the verifier may not automatically detect arena usage
> + * through indirect references, so we provide an explicit reference.
> */
> +#if defined(__BPF_FEATURE_ADDR_SPACE_CAST)
> +/* Modern toolchains don't need the workaround */
> +#define scx_arena_subprog_init() do { } while (0)
> +#else
> +/* Older toolchains need explicit arena reference for verifier */
> static volatile bool scx_arena_verify_once;
>
> __hidden void scx_arena_subprog_init(void)
> @@ -80,9 +80,15 @@ __hidden void scx_arena_subprog_init(void)
> if (scx_arena_verify_once)
> return;
>
> - bpf_printk("%s: arena pointer %p", __func__, &arena);
> + /*
> + * Generate LD.IMM instruction to help BPF verifier track arena usage.
> + * The volatile cast ensures the compiler doesn't optimize away the reference.
> + */
> + (void)*(volatile void **)&arena;
> +
> scx_arena_verify_once = true;
> }
> +#endif
>
>
> private(LOCK) struct bpf_spin_lock alloc_lock;
next prev parent reply other threads:[~2026-02-03 3:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 3:19 zhidao su
2026-02-03 3:54 ` Emil Tsalapatis [this message]
2026-02-03 6:44 ` zhidao su
2026-02-03 6:57 ` zhidao su
2026-02-06 4:18 zhidao su
2026-02-06 7:03 ` Andrea Righi
2026-02-06 16:03 ` Emil Tsalapatis
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=DG50UKIT01F0.13MHQV8KYVF0D@etsalapatis.com \
--to=emil@etsalapatis.com \
--cc=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sched-ext@lists.linux.dev \
--cc=soolaugust@gmail.com \
--cc=suzhidao@xiaomi.com \
--cc=tj@kernel.org \
--cc=void@manifault.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®