Commit 207ee841 authored by Mike Christie's avatar Mike Christie Committed by Nicholas Bellinger

target: Use system workqueue for ALUA transitions

If tcmu-runner is processing a STPG and needs to change the kernel's
ALUA state then we cannot use the same work queue for task management
requests and ALUA transitions, because we could deadlock. The problem
occurs when a STPG times out before tcmu-runner is able to
call into target_tg_pt_gp_alua_access_state_store->
core_alua_do_port_transition -> core_alua_do_transition_tg_pt ->
queue_work. In this case, the tmr is on the work queue waiting for
the STPG to complete, but the STPG transition is now queued behind
the waiting tmr.

This bug will also be fixed by this patch:
which switches the tmr code to use the system workqueues.

For both, I am not sure if we need a dedicated workqueue since
it is not a performance path and I do not think we need WQ_MEM_RECLAIM
to make forward progress to free up memory like the block layer does.
Signed-off-by: default avatarMike Christie <>
Signed-off-by: default avatarNicholas Bellinger <>
parent 0a414572
......@@ -1121,13 +1121,11 @@ static int core_alua_do_transition_tg_pt(
unsigned long transition_tmo;
transition_tmo = tg_pt_gp->tg_pt_gp_implicit_trans_secs * HZ;
} else {
tg_pt_gp->tg_pt_gp_transition_complete = &wait;
&tg_pt_gp->tg_pt_gp_transition_work, 0);
schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, 0);
tg_pt_gp->tg_pt_gp_transition_complete = NULL;
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment