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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 20 Apr 2016 21:45:27 +0800
From:	Xunlei Pang <xpang@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>, 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 2016/04/20 at 21:17, Peter Zijlstra wrote:
> 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.

Sorry, the changelog mentioned a little, I should describe it in detail.

>
> 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.

The patch updates the copy everytime the waiter's policy/runtime/period
are changed. The calling path is rt_mutex_setprio()->rt_mutex_update_copy(),
so it can change very soon after __sched_setscheduler()->rt_mutex_adjust_pi()
is made, also PATCH6 forces to make the update for deadline cases.

This is not acceptable?

Regards,
Xunlei

>
> 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'.
>
>