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

[Andrea Righi <arighi@nvidia.com>]

On Sat, Sep 26, 2026 at 09:34:37PM +0000, sashiko-bot@kernel.org wrote:
> 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?

For the records, as specified in the changelog of the patch, this is fixed by:
https://lore.kernel.org/r/fa6479d36b528573565ca22914451317@kernel.org.

-Andrea