Re: [PATCH v2 sched_ext/for-7.3 28/36] sched_ext: Tie cpu occupancy to SCX_CAP_BASE through the task slice

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Deferred out-of-band slice requests (slice_oob) are ignored and wiped when a task is dispatched or picked, leading to silent loss of the requested slice and potential soft lockups.
--

commit 567d82c10c647e4c761cbfd427050c8d3df5c896
Author: Tejun Heo <tj@kernel.org>

sched_ext: Tie cpu occupancy to SCX_CAP_BASE through the task slice

This commit introduces SCX_CAP_BASE logic to enforce that a task's slice
extension is only allowed when its scheduler holds baseline CPU access.
It stashes out-of-band slice requests in a new slice_oob field to be
applied later under the task's runqueue lock.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c

[ ... ]

> @@ -1164,6 +1283,9 @@ static void update_curr_scx(struct rq *rq)
>  	struct task_struct *curr = rq->curr;
>  	s64 delta_exec;
>  
> +	/* apply even on 0 delta_exec, callers may still act on the slice */
> +	apply_task_slice_oob(rq, curr);
> +
>  	delta_exec = update_curr_common(rq);

[Severity: High]
Does this logic handle tasks that are dispatched before update_curr_scx()
is called?

If a BPF scheduler requests a finite time slice for a queued task via
scx_bpf_task_set_slice() without the rq lock, the request is stashed in
slice_oob.

If the task's old slice was SCX_SLICE_INF, set_next_task_scx() will
evaluate tick dependency based on that stale slice instead of applying
the slice_oob. If SCX_RQ_CAN_STOP_TICK is set and the CPU stops the tick,
update_curr_scx() might not be called, allowing the task to run indefinitely
and ignore the finite slice request.

Could apply_task_slice_oob() be called before tick dependency is evaluated?

[ ... ]

> @@ -2965,7 +3090,7 @@ do_pick_task_scx(struct rq *rq, struct rq_flags *rf, bool force_scx)
>  		if (!p)
>  			return NULL;
>  
> -		if (unlikely(!p->scx.slice)) {
> +		if (unlikely(!p->scx.slice) && scx_task_can_stay_on_cpu(rq, p)) {
>  			struct scx_sched *sch = scx_task_sched(p);
>  
>  			if (!scx_bypassing(sch, cpu_of(rq)) &&

[Severity: High]
Will this silently drop an out-of-band slice request?

When do_pick_task_scx() picks a task with an old slice of 0, it eventually
calls refill_task_slice_dfl(). That function calls set_task_slice(), which
unconditionally clears slice_oob.

Since slice_oob is cleared before the out-of-band request can be applied,
the stashed slice request is lost. Should we apply the slice_oob before
checking if the slice is 0?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706014058.439853-1-tj@kernel.org?part=28