Re: [PATCH] sched_ext: Reject oversized automatic CID shards

[Andrea Righi]

Hi Hui,

On Wed, Oct 21, 2026 at 03:49:46PM +0900, Hui Su wrote:
> Automatic topology packing starts a new shard before adding a core when
> the current shard would exceed its target size. However, a first core is
> always accepted so that cores remain indivisible. An indivisible core with
> more than SCX_CID_SHARD_MAX_CPUS CPUs cannot be represented without
> exceeding the hard shard limit.
> 
> Per-shard state uses fixed-size inline cmask storage sized for
> SCX_CID_SHARD_MAX_CPUS. Passing an oversized shard to alloc_pshard() can
> therefore make cmask initialization overwrite the following fields.
> 
> Reject an indivisible core larger than SCX_CID_SHARD_MAX_CPUS before adding
> it to a shard. Existing non-empty shard splitting already keeps the total
> within the hard cap, while an indivisible core may still exceed
> cid_shard_size when it fits within the hard limit.
> 
> Fixes: e2c841b91bf9 ("sched_ext: Add CID sharding")
> Signed-off-by: Hui Su <sh_def@xxxxxxx>
> ---
>  kernel/sched/ext/cid.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/sched/ext/cid.c b/kernel/sched/ext/cid.c
> index 4b08866d75f6..3c38650d78d5 100644
> --- a/kernel/sched/ext/cid.c
> +++ b/kernel/sched/ext/cid.c
> @@ -287,6 +287,9 @@ s32 scx_cid_init(struct scx_sched *sch)
>  				 * empty shard.
>  				 */
>  				cids_in_core = cpumask_weight(core_scratch);
> +				if (cids_in_core > SCX_CID_SHARD_MAX_CPUS)
> +					return -E2BIG;
> +

This requires more than 512 SMT siblings in a single core, which doesn't
exist on real hardware, but it's possible to trigger with a synthetic
topology (unlikely in practice, but not impossible).

In fact, I've reproduced this with virtme-ng (and CONFIG_MAXSMP=y):

$ vng --disable-microvm --cpus 600,sockets=1,cores=1,threads=600 -m 4G \
       --qemu-opts='-machine q35,kernel-irqchip=split'

Without this patch, loading scx_qmap triggers the WARN_ON_ONCE() in
__scx_cmask_init() and then panics with stack corruption in
scx_bpf_sub_caps(). With this patch, the scheduler is rejected with
-E2BIG.

However, the only thing reported is "scx_root_enable() failed (-7)",
which doesn't say much about what went wrong. Can we report the reason
with scx_error(), similar to what scx_bpf_cid_override() does for
oversized shards? Something like:

	if (cids_in_core > SCX_CID_SHARD_MAX_CPUS) {
		scx_error(sch, "core with %u cpus exceeds max shard size %d",
			  cids_in_core, SCX_CID_SHARD_MAX_CPUS);
		return -E2BIG;
	}

With that addressed, feel free to add:

Reviewed-by: Andrea Righi <arighi@xxxxxxxxxx>
Tested-by: Andrea Righi <arighi@xxxxxxxxxx>

Thanks,
-Andrea

>  				max_cores = cores_per_shard + (shard_local < nr_large ? 1 : 0);
>  				if (cores_in_shard &&
>  				    (cores_in_shard >= max_cores ||
> 
>