summaryrefslogtreecommitdiff
path: root/kernel/torture.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2014-06-05 12:31:32 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2014-06-05 12:31:32 -0700
commit1c5aefb5b12a90e29866c960a57c1f8f75def617 (patch)
tree038ed51fcd95c37b5a1b1e22de1a5de06ac6640a /kernel/torture.c
parent54539cd217d687d9acf385eab22ec02b3f7a86a0 (diff)
parent54a217887a7b658e2650c3feff22756ab80c7339 (diff)
Merge branch 'futex-fixes' (futex fixes from Thomas Gleixner)
Merge futex fixes from Thomas Gleixner: "So with more awake and less futex wreckaged brain, I went through my list of points again and came up with the following 4 patches. 1) Prevent pi requeueing on the same futex I kept Kees check for uaddr1 == uaddr2 as a early check for private futexes and added a key comparison to both futex_requeue and futex_wait_requeue_pi. Sebastian, sorry for the confusion yesterday night. I really misunderstood your question. You are right the check is pointless for shared futexes where the same physical address is mapped to two different virtual addresses. 2) Sanity check atomic acquisiton in futex_lock_pi_atomic That's basically what Darren suggested. I just simplified it to use futex_top_waiter() to find kernel internal state. If state is found return -EINVAL and do not bother to fix up the user space variable. It's corrupted already. 3) Ensure state consistency in futex_unlock_pi The code is silly versus the owner died bit. There is no point to preserve it on unlock when the user space thread owns the futex. What's worse is that it does not update the user space value when the owner died bit is set. So the kernel itself creates observable inconsistency. Another "optimization" is to retry an atomic unlock. That's pointless as in a sane environment user space would not call into that code if it could have unlocked it atomically. So we always check whether there is kernel state around and only if there is none, we do the unlock by setting the user space value to 0. 4) Sanitize lookup_pi_state lookup_pi_state is ambigous about TID == 0 in the user space value. This can be a valid state even if there is kernel state on this uaddr, but we miss a few corner case checks. I tried to come up with a smaller solution hacking the checks into the current cruft, but it turned out to be ugly as hell and I got more confused than I was before. So I rewrote the sanity checks along the state documentation with awful lots of commentry" * emailed patches from Thomas Gleixner <tglx@linutronix.de>: futex: Make lookup_pi_state more robust futex: Always cleanup owner tid in unlock_pi futex: Validate atomic acquisition in futex_lock_pi_atomic() futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)
Diffstat (limited to 'kernel/torture.c')
0 files changed, 0 insertions, 0 deletions