scsi: zfcp: Clarify access to erp_action in zfcp_fsf_req_complete()
authorJulian Wiedmann <jwi@linux.ibm.com>
Thu, 10 Sep 2020 19:49:16 +0000 (21:49 +0200)
committerMartin K. Petersen <martin.petersen@oracle.com>
Tue, 15 Sep 2020 22:01:58 +0000 (18:01 -0400)
commitd251193d17321d44f96b78d9bb4c8b8ea6786e72
tree29a65f1cc3abd73acae28d3e2944215efc3eeb60
parentaddf1372961523cc8cb7ab4ee26d5e1373bf64a0
scsi: zfcp: Clarify access to erp_action in zfcp_fsf_req_complete()

While reviewing commit 936e6b85da04 ("scsi: zfcp: Fix panic on ERP timeout
for previously dismissed ERP action"), I stumbled over
zfcp_fsf_req_complete() and wondered whether it has similar issues wrt
concurrent modification of req->erp_action by
zfcp_erp_strategy_check_fsfreq().

But a closer look shows that both its two callers [zfcp_fsf_reqid_check(),
zfcp_fsf_req_dismiss_all()] remove the request from the adapter's req_list
under the req_list's lock.  Hence we can trust that if
zfcp_erp_strategy_check_fsfreq() concurrently looks up the corresponding
req_id, it won't find this request and is thus unable to modify it while
it's being processed by zfcp_fsf_req_complete().

Add a code comment that hopefully makes this easier for future readers, and
condense the two accesses to ->erp_action that made me trip over this code
path in the first place.

Link: https://lore.kernel.org/r/c500eac301fcbba5af942bbd200f2d6b14e46994.1599765652.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/s390/scsi/zfcp_fsf.c