linux-kernel - Re: [PATCH v3 5/6] sched/deadline/rtmutex: Fix unprotected PI access in enqueue_task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Apr 2016 15:17:37 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	xlpang@...hat.com
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Juri Lelli <juri.lelli@....com>,
	Ingo Molnar <mingo@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v3 5/6] sched/deadline/rtmutex: Fix unprotected PI access
 in enqueue_task_dl()

On Wed, Apr 20, 2016 at 09:00:32PM +0800, Xunlei Pang wrote:

> > But what happens? How is it changed when it is blocked?
> 
> The top waiter's policy can be changed by other tasks through sched_setattr() syscall during it was blocked.
> I created another thread doing the following thing:
>      while (1) {
>         change the waiter to cfs
>         do something
>         change the waiter to deadline
>     }

Indeed; so why didn't you say that? That is the single most important
thing in the Changelog -- the _actual_ problem, and you left it out.

I'm not quite sure how to go fix that best, but copying the state is not
right. That precludes being able to change the state.

There's two (obvious but) rather ugly solutions:

 - delay the __sched_setscheduler() call until such a time that the task
   is no longer the top waiter.

 - deboost + __sched_setscheduler() + boost

Both have a different set of problems, but both keep the p->pi_task
pointer and its state 'stable'.