summaryrefslogtreecommitdiff
path: root/block/blk-exec.c
diff options
context:
space:
mode:
authorSteven Rostedt <rostedt@goodmis.org>2014-03-04 17:28:32 (GMT)
committerScott Wood <scottwood@freescale.com>2014-05-14 18:38:37 (GMT)
commitecb0069c91d00cf11a9b60eab0c81b24604ba4f3 (patch)
treec8e33d938f613c3cc6807b165b6f188afa71aaf0 /block/blk-exec.c
parent37fc3173215bf467bb50351f5aa659c730e2b10e (diff)
downloadlinux-fsl-qoriq-ecb0069c91d00cf11a9b60eab0c81b24604ba4f3.tar.xz
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>
Diffstat (limited to 'block/blk-exec.c')
0 files changed, 0 insertions, 0 deletions