summaryrefslogtreecommitdiff
path: root/kernel/module_signing.c
diff options
context:
space:
mode:
authorSteven Rostedt <rostedt@goodmis.org>2014-03-04 17:28:32 (GMT)
committerScott Wood <scottwood@freescale.com>2015-02-13 22:20:54 (GMT)
commit311dd05c536ff77b64c21d51fd0b7103e0278ec4 (patch)
tree652bc3874e87b77e1d0a662e9b03f5699658b916 /kernel/module_signing.c
parentcfda299391da24e4cb371e409402d4dc85bedc96 (diff)
downloadlinux-fsl-qoriq-311dd05c536ff77b64c21d51fd0b7103e0278ec4.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 'kernel/module_signing.c')
0 files changed, 0 insertions, 0 deletions