From: Zhijian Han <hanzhijian1991@gmail.com>
To: bpf@vger.kernel.org, sched-ext@lists.linux.dev
Cc: daniel@iogearbox.net, tj@kernel.org, ast@kernel.org,
void@manifault.com, arighi@nvidia.com,
linux-kernel@vger.kernel.org,
Zhijian Han <hanzhijian1991@gmail.com>
Subject: sched_ext selftest enable_cmask fails to load on 7.4-rc2: verifier rejects arena pointer cast from scx_enable_args.cmask_arena_addr
Date: Mon, 9 Nov 2026 23:25:32 +0800 [thread overview]
Message-ID: <6af1e5f2.a438010f.130489.ab94@mx.google.com> (raw)
From: Zhijian Han <hanzhijian1991@gmail.com>
Hello,
The enable_cmask selftest (tools/testing/selftests/sched_ext/, added in
the recent merge window via d781d1b78acf "selftests/sched_ext: Check the
cmask cid-form ops.enable() receives") fails to load on v7.4-rc2 and
linux-next-20261105. The BPF program enable_cmask_enable is rejected by
the verifier at load time:
libbpf: prog 'enable_cmask_enable': BPF program load failed: -EACCES
94: (61) r1 = *(u32 *)(r8 +0)
R8 invalid mem access 'scalar'
Verification failed: Register Type Safety: Invalid dereference
The test follows the usage documented in kernel/sched/ext/internal.h:
struct scx_enable_args {
u64 cmask_arena_addr;
};
/*
* ... The address is a plain value rather than a typed pointer ...
* Cast it to struct scx_cmask __arena * before use.
*/
i.e. enable_cmask.bpf.c:101:
struct scx_cmask __arena *m =
(struct scx_cmask __arena *)args->cmask_arena_addr;
The C cast does not emit an addr_space_cast insn: in the generated
bytecode the member load (insn 1: r7 = *(u64 *)(r2 + 0)) produces
R7=scalar(), which stays scalar across the cast and the inlined
check_mask() prologue, so the first dereference m->base (insn 94) is
rejected.
The same selftest was verified by Tejun on the for-7.3-fixes branch
(per the v3 cover letter, 20260919002838.1960071-1-tj, 16-CPU VM, three
standalone runs plus the full suite); the verifier-side arena handling
that changed during the 7.4 merge window appears to no longer accept
this pattern. The struct_ops argument path (direct __arena args, e.g.
ops.set_cmask) still works — only the u64-carried address form is
affected.
Reproducer (deterministic, two consecutive runs identical):
# kernel: defconfig + SCHED_CLASS_EXT, DEBUG_INFO_BTF, FUNCTION_TRACER
make O=build -j$(nproc)
cd tools/testing/selftests/sched_ext
make LLVM=1 O=$PWD/../../../../../build OUTPUT=out/ TEST_GEN_MODS_DIR=
# initrd with out/runner + out/build + libs + busybox + kernel .config
# at /boot/config-$(uname -r); then:
qemu-system-x86_64 -enable-kvm -smp 4 -m 2G -nographic \
-kernel build/arch/x86/boot/bzImage -initrd initrd.cpio.gz \
-append "console=ttyS0"
/root # ./runner -t enable_cmask
not ok 1 enable_cmask #
Tested on:
v7.4-rc2 (7475ea8b5): FAIL (verifier rejects at load)
next-20261105 (gddfe51b0a0f5): FAIL (same rejection)
v7.3: SKIP (struct scx_enable_args not present)
Compiler versions tried: clang 18 and clang 19 — identical bytecode
around the failing insn, identical rejection, so this does not look
compiler-dependent.
The other 40 tests in the suite pass on both 7.4-rc2 and next (after
enabling CONFIG_FUNCTION_TRACER, without which the fentry-based tests
maximal/kick_immediate/reload_loop fail with -EBUSY — worth a note in
the selftest docs, but that part is config, not a bug).
Possible directions (not investigated in depth):
- a kfunc or verifier-supported way to convert the u64 carried in
scx_enable_args into a PTR_TO_ARENA,
- or an __arena-typed member/alias in scx_enable_args once BTF can
express arena pointer members (the internal.h comment already
anticipates this),
- or adjusting the test to obtain the cmask through a path the
verifier accepts.
Full verifier log and QEMU boot log available on request.
Signed-off-by: Zhijian Han <hanzhijian1991@gmail.com>
reply other threads:[~2026-11-09 15:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=6af1e5f2.a438010f.130489.ab94@mx.google.com \
--to=hanzhijian1991@gmail.com \
--cc=arighi@nvidia.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=linux-kernel@vger.kernel.org \
--cc=sched-ext@lists.linux.dev \
--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®