Re: [PATCH] sched: Fix cpuset_mutex double unlock in __sched_setscheduler()

[Kayra Cizmeci]

On Mon, Nov 02, 2026 at 02:46:05PM +0100, Andrea Parri wrote:
:
> A sched_setattr() with SCHED_FLAG_KEEP_POLICY on a SCHED_DEADLINE task
> unlocks cpuset_mutex twice if the task's policy changes concurrently:

Uh-oh.

>  kernel/sched/syscalls.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
> index 45a127deeadd9..2af550f92ac65 100644
> --- a/kernel/sched/syscalls.c
> +++ b/kernel/sched/syscalls.c
> @@ -640,8 +640,10 @@ int __sched_setscheduler(struct task_struct *p,
>  	if (unlikely(oldpolicy != -1 && oldpolicy != p->policy)) {
>  		policy = oldpolicy = -1;
>  		task_rq_unlock(rq, p, &rf);
> -		if (cpuset_locked)
> +		if (cpuset_locked) {
>  			cpuset_unlock();
> +			cpuset_locked = false;
> +		}
>  		goto recheck;
>  	}
>  
> -- 
> 2.53.0
> 

So the issue is that when tasks policy changes before we come to this
check, we don't clear cpuset_locked while calling cpuset_unlock().

In the other calls of cpuset_unlock() this is not a problem since we
just return and don't use the local cpuset_locked. But on this one we
do. And if we don't retake the lock it just stays true. Even if we
didn't claimed the lock. And that causes bad, bad, bad, bad problems.

Reviewed-by: Kayra Cizmeci <kayracizmeci@xxxxxxxxx>


Thanks,

Kayra