summaryrefslogtreecommitdiffstats
path: root/kernel/stop_machine.c
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2014-06-11 20:45:38 +0000
committerThomas Gleixner <tglx@linutronix.de>2014-06-21 22:26:23 +0200
commitccf9e6a80d9e1b9df69c98e6b9745cf49869ee15 (patch)
tree37da57e39262f0852466b62930dcbc005ce1800b /kernel/stop_machine.c
parent67792e2cabadbadd1a93f6790fa7bcbd47eca7c3 (diff)
downloadop-kernel-dev-ccf9e6a80d9e1b9df69c98e6b9745cf49869ee15.zip
op-kernel-dev-ccf9e6a80d9e1b9df69c98e6b9745cf49869ee15.tar.gz
futex: Make unlock_pi more robust
The kernel tries to atomically unlock the futex without checking whether there is kernel state associated to the futex. So if user space manipulated the user space value, this will leave kernel internal state around associated to the owner task. For robustness sake, lookup first whether there are waiters on the futex. If there are waiters, wake the top priority waiter with all the proper sanity checks applied. If there are no waiters, do the atomic release. We do not have to preserve the waiters bit in this case, because a potentially incoming waiter is blocked on the hb->lock and will acquire the futex atomically. We neither have to preserve the owner died bit. The caller is the owner and it was supposed to cleanup the mess. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Darren Hart <darren@dvhart.com> Cc: Davidlohr Bueso <davidlohr@hp.com> Cc: Kees Cook <kees@outflux.net> Cc: wad@chromium.org Link: http://lkml.kernel.org/r/20140611204237.016987332@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'kernel/stop_machine.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud