Created attachment 2154340 [details]
Inside this you will find the btf

Description of problem:

No sched_ext scheduler can be loaded on stock Fedora kernels. scx_loader retries
five times and gives up; the schedulers fail in libbpf with:

  libbpf: extern (func ksym) 'scx_bpf_create_dsq': func_proto [N] incompatible with vmlinux [M]
  libbpf: failed to load BPF skeleton

The root cause is a build-dependency issue, not a kernel code bug.

Kernel 7.0 introduced kfuncs with KF_IMPLICIT_ARGS, which carry a trailing implicit
'aux' parameter in their C definition. The public BTF prototype must be emitted
without that parameter. This cleanup is performed at build time by
resolve_btfids/btf2btf, and it is driven by the DECL_TAG 'bpf_kfunc' annotations
that pahole attaches to each kfunc.

scripts/Makefile.btf only passes --btf_features=decl_tag_kfuncs to pahole from
pahole 1.26 onwards, and the emission of these tags for KF_IMPLICIT_ARGS kfuncs
works correctly only from pahole 1.31. Fedora 44 ships dwarves 1.30 in the base
repository, so the kernel is built without those tags. Consequently the affected
kfuncs keep their raw prototypes, including the implicit argument, and libbpf
rejects them.

Version-Release number of selected component:

kernel-7.1.8-200.fc44.x86_64
dwarves-1.30-3.fc44
scx-scheds-1.1.2-2.fc44

Steps to Reproduce:

1. dnf install scx-scheds
2. systemctl start scx_loader   (or run any scheduler, e.g. scx_rusty, directly)
3. journalctl -u scx_loader

Actual results:

The scheduler never attaches. libbpf reports the kfunc prototypes as incompatible
with vmlinux BTF and the BPF skeleton fails to load.

Expected results:

The scheduler attaches and sched_ext becomes active. Both kernels have
CONFIG_SCHED_CLASS_EXT=y, so this is expected to work.

Additional info — measured evidence:

Shipped BTF of kernel 7.1.8-200.fc44 (extracted with
"objcopy --dump-section .BTF" from kernel-debuginfo), compared against a BTF
regenerated from the very same vmlinux with pahole 1.31 (from copr
bieszczaders/kernel-cachyos-addons):

  pahole -j --btf_encode_detached=new.btf \
    --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func,decl_tag_kfuncs \
    /usr/lib/debug/lib/modules/7.1.8-200.fc44.x86_64/vmlinux

                                          shipped BTF     regenerated
                                          (dwarves 1.30)  (pahole 1.31)
  scx_bpf_* funcs with DECL_TAG bpf_kfunc  40 of 78        54 of 54
  DECL_TAG 'bpf_kfunc' total               270             285

The 15-tag difference matches exactly the set of kfuncs that fail. Example, in the
shipped BTF:

  [139471] FUNC 'scx_bpf_create_dsq' type_id=63996 linkage=static
  [63996]  FUNC_PROTO '(anon)' ret_type_id=138446 vlen=3
           'dsq_id' type_id=38
           'node'   type_id=34
           'aux'    type_id=11602      <-- implicit arg, should not be here

with no DECL_TAG 'bpf_kfunc' referring to type 139471. A kfunc that *was* tagged at
build time came out correct, e.g. scx_bpf_dsq_nr_queued -> FUNC_PROTO ... vlen=1
with only 'dsq_id'.

The kernel verifier itself handles KF_IMPLICIT_ARGS correctly; only the libbpf-side
signature check fails, and it fails purely because of the missing tags in BTF.

Suggested fix:

Bump the kernel package build requirement to dwarves >= 1.31. Rebuilding with
pahole 1.31 makes resolve_btfids prune the implicit arguments from all kfuncs,
which is what the libbpf check expects.

Notes:

- Also reproduced on kernel-cachyos 7.1.5 (copr bieszczaders/kernel-cachyos) — the
  same bump is needed there.
- The pahole-generated detached BTF is NOT a usable workaround via btf_custom_path:
  pahole emits the tags but does not prune the implicit argument (there
  scx_bpf_dsq_nr_queued is vlen=2, 'dsq_id' + 'aux'), so such a BTF breaks even the
  kfuncs that currently work. The pruning must happen during the kernel build.