]> rtime.felk.cvut.cz Git - zynq/linux.git/commit
cpu_chill: Add a UNINTERRUPTIBLE hrtimer_nanosleep
authorSteven Rostedt <rostedt@goodmis.org>
Tue, 4 Mar 2014 17:28:32 +0000 (12:28 -0500)
committerMichal Sojka <sojka@merica.cz>
Sun, 13 Sep 2015 07:47:30 +0000 (09:47 +0200)
commitc2676a65d2a4145c931dcfb45bc136e9498a16dd
treea73423b2c08f642c553d5d124e016dc6fc11a3e5
parent5cce3da635e48631034d1ea2c7beb3552b16dc0f
cpu_chill: Add a UNINTERRUPTIBLE hrtimer_nanosleep

We hit another bug that was caused by switching cpu_chill() from
msleep() to hrtimer_nanosleep().

This time it is a livelock. The problem is that hrtimer_nanosleep()
calls schedule with the state == TASK_INTERRUPTIBLE. But these means
that if a signal is pending, the scheduler wont schedule, and will
simply change the current task state back to TASK_RUNNING. This
nullifies the whole point of cpu_chill() in the first place. That is,
if a task is spinning on a try_lock() and it preempted the owner of the
lock, if it has a signal pending, it will never give up the CPU to let
the owner of the lock run.

I made a static function __hrtimer_nanosleep() that takes a fifth
parameter "state", which determines the task state of that the
nanosleep() will be in. The normal hrtimer_nanosleep() will act the
same, but cpu_chill() will call the __hrtimer_nanosleep() directly with
the TASK_UNINTERRUPTIBLE state.

cpu_chill() only cares that the first sleep happens, and does not care
about the state of the restart schedule (in hrtimer_nanosleep_restart).

Cc: stable-rt@vger.kernel.org
Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
kernel/time/hrtimer.c