Re: [PATCH v4 sched_ext/for-7.3 29/40] sched_ext: Route task slice writes through set_task_slice()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Data race on a running task's slice (`p->scx.slice`) between the kernel runqueue update and concurrent BPF kfunc execution.
--

--- Patch [29]: [PATCH v4 sched_ext/for-7.3 29/40] sched_ext: Route task slice writes through set_task_slice() ---
commit 89b48440e365b5adf1131b995d2e06c22b4e11aa
Author: Tejun Heo <tj@kernel.org>

sched_ext: Route task slice writes through set_task_slice()

This commit introduces set_task_slice() and routes BPF-triggered writes
to p->scx.slice through it. This centralizes the writes in preparation for
a later change to handle pending out-of-band slice requests.

> 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

[ ... ]

> @@ -8651,7 +8657,7 @@ __bpf_kfunc bool scx_bpf_task_set_slice(struct task_struct *p, u64 slice,
>  	if (unlikely(!sch || !scx_task_on_sched(sch, p)))
>  		return false;
>  
> -	p->scx.slice = slice;
> +	set_task_slice(p, slice);

[Severity: High]
This is a pre-existing issue, but does this lockless write to the task's
slice create a dangerous data race with update_curr_scx()?

When a BPF program locklessly calls scx_bpf_task_set_slice() on a running
task, it races with the CPU executing update_curr_scx() under the runqueue
lock. In update_curr_scx(), the slice is updated using min_t():

    curr->scx.slice -= min_t(u64, curr->scx.slice, delta_exec);

Because the min_t() macro evaluates its arguments multiple times,
curr->scx.slice can be read once for the comparison, then concurrently
updated to a very small value by BPF, and read again for the subtraction.
This could result in an integer underflow, giving the task a near-infinite
slice and potentially monopolizing the CPU.

Since the commit message mentions this is in preparation for a later change
that handles out-of-band slice requests, does that subsequent change
mitigate this data race?

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