Hi Waiman,
On 29/06/26 23:33, Waiman Long wrote:
> The nr_deadline_tasks variable in the cpuset structure was introduced by
> commit 6c24849f5515 ("sched/cpuset: Keep track of SCHED_DEADLINE task
> in cpusets"). It is reported by sashiko [1] that nr_deadline_tasks
> can currently be modified by inc_dl_tasks_cs() under rq->lock and
> by cpuset_attach() under cpuset_mutex. So if both updates happen
> simultaneously, the nr_deadline_tasks variable can be corrupted leading
> to incorrect operations down the road.
>
> Fix that by changing its type to atomic_t so that nr_deadline_tasks are
> always atomically updated.
>
> [1]
> https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.comk
>
> Fixes: 6c24849f5515 ("sched/cpuset: Keep track of SCHED_DEADLINE task in
> cpusets")
> Signed-off-by: Waiman Long <[email protected]>
> ---
Looks like Sashiko is yet not completely happy with this:
https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com
I actually wondered the same and couldn't convince myself we don't
actually have that problem with the window between sched_setscheduler()
and cpuset_attach(). If issue is confirmed, not sure if wait_attach_
done_lock() could help here as well? It's kind of a big lock for the
scheduler, but maybe only affecting DEADLINE tasks and if migrations
are ongoing.
Thanks,
Juri
