Re: [PATCH v2 sched_ext/for-7.4] sched_ext: cid: Represent clusters explicitly

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] bpf: scx_bpf_cid_topo UAPI break due to struct scx_cid_topo size change
--

commit fb59a730e3e34d8a0c1fda134fb4459d8183c802
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: cid: Represent clusters explicitly

This commit adds explicit cluster representation to the sched_ext CID
topology. It modifies the cid calculation logic and updates
struct scx_cid_topo to include cluster_cid and cluster_idx.

Link: https://lore.kernel.org/r/20260926152306.3190774-1-arighi@nvidia.com

> diff --git a/kernel/sched/ext/types.h b/kernel/sched/ext/types.h
> index 943d8d429a2c9..765d7b9208144 100644
> --- a/kernel/sched/ext/types.h
> +++ b/kernel/sched/ext/types.h

[ ... ]

> @@ -88,6 +95,8 @@ struct scx_cid_topo {
>  	s32 node_idx;
>  	s32 shard_cid;
>  	s32 shard_idx;
> +	s32 cluster_cid;
> +	s32 cluster_idx;
>  };

[Severity: Critical]
Will adding cluster_cid and cluster_idx break existing BPF schedulers that
call scx_bpf_cid_topo()?

By increasing the size of struct scx_cid_topo from 32 to 40 bytes, the
expected argument size for the kfunc changes. Since scx_bpf_cid_topo()
lacks a size-aware __sz parameter or compatibility wrapper:

kernel/sched/ext/cid.c:scx_bpf_cid_topo() {
    ...
    *out__uninit = topo[cid];
}

Could the BPF verifier strictly reject older BPF schedulers passing a
32-byte allocation because out__uninit demands the current kernel's BTF size?

Furthermore, if the check were somehow bypassed, would the assignment cause
an 8-byte out-of-bounds write into BPF stack or map memory?

Does this constitute a hard ABI break for existing userspace binaries since
they lack a deprecation path or versioning wrapper?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926212017.3351797-1-arighi@nvidia.com?part=1