mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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®