Searched refs:exp_mutex (Results 1 – 7 of 7) sorted by relevance
104 mutex_lock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_free()109 mutex_unlock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_free()321 mutex_lock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_setup()405 mutex_unlock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_setup()496 mutex_lock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_clear()509 mutex_unlock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_clear()
340 mutex_init(&rcd->exp_mutex); in hfi1_create_ctxtdata()
269 struct mutex exp_mutex; member
311 mutex_trylock(&rcu_state.exp_mutex)) in exp_funnel_lock()343 mutex_lock(&rcu_state.exp_mutex); in exp_funnel_lock()346 mutex_unlock(&rcu_state.exp_mutex); in exp_funnel_lock()980 mutex_unlock(&rcu_state.exp_mutex); in synchronize_rcu_expedited()
386 struct mutex exp_mutex; /* Serialize expedited GP. */ member
100 .exp_mutex = __MUTEX_INITIALIZER(rcu_state.exp_mutex),
351 Task A now acquires the ``rcu_state`` structure's ``->exp_mutex`` and368 releases the ``->exp_mutex``. This results in the following state:372 Task E can then acquire ``->exp_mutex`` and increment397 | prevent it from releasing ``->exp_mutex``, which in turn will prevent |421 wakeups start. This is handled by having the ``->exp_mutex`` guard423 wakeups. The key point is that the ``->exp_mutex`` is not released until