locking/rtmutex: Explain locking rules for rt_mutex_proxy_unlock()/init_proxy_locked()
authorThomas Gleixner <tglx@linutronix.de>
Wed, 30 Nov 2016 21:04:45 +0000 (21:04 +0000)
committerIngo Molnar <mingo@kernel.org>
Fri, 2 Dec 2016 10:13:57 +0000 (11:13 +0100)
commit84d82ec5b9046ecdf16031d3e93a66ef50257402
tree716c8ca677edf6cc92677f7a647cdd9bfa641af9
parentb5016e8203003c44264ec88fe2276ff54a51f689
locking/rtmutex: Explain locking rules for rt_mutex_proxy_unlock()/init_proxy_locked()

While debugging the unlock vs. dequeue race which resulted in state
corruption of futexes the lockless nature of rt_mutex_proxy_unlock()
caused some confusion.

Add commentry to explain why it is safe to do this lockless. Add matching
comments to rt_mutex_init_proxy_locked() for completeness sake.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: David Daney <ddaney@caviumnetworks.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Deacon <will.deacon@arm.com>
Link: http://lkml.kernel.org/r/20161130210030.591941927@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
kernel/locking/rtmutex.c