Lines Matching refs:wait_lock

210 wait_lock.  Since the modification of the waiter list is never done in
211 interrupt context, the wait_lock can be taken without disabling interrupts.
457 Next, we look at the mutex that the task is blocked on. The mutex's wait_lock
459 pi_lock and wait_lock goes in the opposite direction. If we fail to grab the
462 Now that we have both the pi_lock of the task as well as the wait_lock of
484 wait_lock, and continue the loop again.  On the next iteration of the
489       since we just grab the mutex's wait_lock. And one could be right.
501       the protection of the mutex's wait_lock, which was not taken yet.
505       wait_lock.  If we fail that lock, we release the pi_lock of the
508       In the code to release the lock, the wait_lock of the mutex is held
512       wait_lock, the unlocking code would spin on the new owner's pi_lock
513       but never give up the wait_lock.  So the PI chain loop is guaranteed to
514       fail the spin_trylock on the wait_lock, release the pi_lock, and
575 The wait_lock of the mutex is taken since the slow path of unlocking the
590 slow unlock path, and it would then need to grab the wait_lock, which this
671 Since the wait_lock was taken at the entry of the slow lock, we can safely
680 (or deadlock checking is on), we unlock the wait_lock of the mutex and go ahead
728 The first thing done in the slow unlock path is to take the wait_lock of the
737 the grabbing of the wait_lock, the mutex may not have any waiters, thus the
739 owner field is set to NULL, the wait_lock is released and nothing more is