Searched refs:exp_mutex (Results 1 – 7 of 7) sorted by relevance
143 mutex_lock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_free()148 mutex_unlock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_free()353 mutex_lock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_setup()439 mutex_unlock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_setup()495 mutex_lock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_clear()508 mutex_unlock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_clear()
381 mutex_init(&rcd->exp_mutex); in hfi1_create_ctxtdata()
310 struct mutex exp_mutex; member
290 mutex_trylock(&rcu_state.exp_mutex)) in exp_funnel_lock()322 mutex_lock(&rcu_state.exp_mutex); in exp_funnel_lock()325 mutex_unlock(&rcu_state.exp_mutex); in exp_funnel_lock()858 mutex_unlock(&rcu_state.exp_mutex); in synchronize_rcu_expedited()
325 struct mutex exp_mutex; /* Serialize expedited GP. */ member
94 .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