target: Fix ALUA transition state race between multiple initiators
authorMike Christie <mchristi@redhat.com>
Wed, 29 Mar 2017 05:19:24 +0000 (00:19 -0500)
committerNicholas Bellinger <nab@linux-iscsi.org>
Fri, 31 Mar 2017 06:12:40 +0000 (23:12 -0700)
commitd19c4643a52f0a56a7ccc86b145f207a57f40116
tree869b8ea9d02571f9fdd7b62902aafd22a28d6d27
parent7a56dc8888be23f44158a85b92da45d545cbf548
target: Fix ALUA transition state race between multiple initiators

Multiple threads could be writing to alua_access_state at
the same time, or there could be multiple STPGs in flight
(different initiators sending them or one initiator sending
them to different ports), or a combo of both and the
core_alua_do_transition_tg_pt calls will race with each other.

Because from the last patches we no longer delay running
core_alua_do_transition_tg_pt_work, there does not seem to be
any point in running that in a workqueue. And, we always
wait for it to complete one way or another, so we can sleep
in this code path. So, this patch made over target-pending just adds a
mutex and does the work core_alua_do_transition_tg_pt_work was doing in
core_alua_do_transition_tg_pt.

There is also no need to use an atomic for the
tg_pt_gp_alua_access_state. In core_alua_do_transition_tg_pt we will
test and set it under the transition mutex. And, it is a int/32 bits
so in the other places where it is read, we will never see it partially
updated.

Signed-off-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
drivers/target/target_core_alua.c
drivers/target/target_core_configfs.c
include/target/target_core_base.h