summaryrefslogtreecommitdiff
path: root/drivers/target/Makefile
diff options
context:
space:
mode:
authorMike Christie <mchristi@redhat.com>2017-03-29 08:19:24 +0300
committerNicholas Bellinger <nab@linux-iscsi.org>2017-03-31 09:12:40 +0300
commitd19c4643a52f0a56a7ccc86b145f207a57f40116 (patch)
tree869b8ea9d02571f9fdd7b62902aafd22a28d6d27 /drivers/target/Makefile
parent7a56dc8888be23f44158a85b92da45d545cbf548 (diff)
downloadlinux-d19c4643a52f0a56a7ccc86b145f207a57f40116.tar.xz
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>
Diffstat (limited to 'drivers/target/Makefile')
0 files changed, 0 insertions, 0 deletions