diff options
author | Thomas Gleixner <[email protected]> | 2014-05-12 20:45:34 +0000 |
---|---|---|
committer | Thomas Gleixner <[email protected]> | 2014-05-19 21:18:49 +0900 |
commit | 866293ee54227584ffcb4a42f69c1f365974ba7f (patch) | |
tree | 5ecf5d09dc2348c583790d4d1cc308aaca4870be /net/unix/af_unix.c | |
parent | d6d211db37e75de2ddc3a4f979038c40df7cc79c (diff) |
futex: Add another early deadlock detection check
Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
detection code of rtmutex:
http://lkml.kernel.org/r/[email protected]
That underlying issue has been fixed with a patch to the rtmutex code,
but the futex code must not call into rtmutex in that case because
- it can detect that issue early
- it avoids a different and more complex fixup for backing out
If the user space variable got manipulated to 0x80000000 which means
no lock holder, but the waiters bit set and an active pi_state in the
kernel is found we can figure out the recursive locking issue by
looking at the pi_state owner. If that is the current task, then we
can safely return -EDEADLK.
The check should have been added in commit 59fa62451 (futex: Handle
futex_pi OWNER_DIED take over correctly) already, but I did not see
the above issue caused by user space manipulation back then.
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Dave Jones <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Darren Hart <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Clark Williams <[email protected]>
Cc: Paul McKenney <[email protected]>
Cc: Lai Jiangshan <[email protected]>
Cc: Roland McGrath <[email protected]>
Cc: Carlos ODonell <[email protected]>
Cc: Jakub Jelinek <[email protected]>
Cc: Michael Kerrisk <[email protected]>
Cc: Sebastian Andrzej Siewior <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Diffstat (limited to 'net/unix/af_unix.c')
0 files changed, 0 insertions, 0 deletions