Searched refs:exp_mutex (Results 1 – 7 of 7) sorted by relevance
107 mutex_lock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_free()112 mutex_unlock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_free()324 mutex_lock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_setup()408 mutex_unlock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_setup()499 mutex_lock(&uctxt->exp_mutex); in hfi1_user_exp_rcv_clear()512 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
293 mutex_trylock(&rcu_state.exp_mutex)) in exp_funnel_lock()325 mutex_lock(&rcu_state.exp_mutex); in exp_funnel_lock()328 mutex_unlock(&rcu_state.exp_mutex); in exp_funnel_lock()1009 mutex_unlock(&rcu_state.exp_mutex); in synchronize_rcu_expedited()
364 struct mutex exp_mutex; /* Serialize expedited GP. */ member
92 .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
Completed in 26 milliseconds