OSDN Git Service

scsi: target: iscsi: Fix cmd abort fabric stop race
authorMike Christie <michael.christie@oracle.com>
Sat, 14 Nov 2020 01:46:18 +0000 (19:46 -0600)
committerMartin K. Petersen <martin.petersen@oracle.com>
Tue, 17 Nov 2020 04:34:18 +0000 (23:34 -0500)
commitf36199355c64a39fe82cfddc7623d827c7e050da
tree80dfecc860f380cfe737f625add36eb7f8952724
parentfe0a8a95e7134d0b44cd407bc0085b9ba8d8fe31
scsi: target: iscsi: Fix cmd abort fabric stop race

Maurizio found a race where the abort and cmd stop paths can race as
follows:

 1. thread1 runs iscsit_release_commands_from_conn and sets
    CMD_T_FABRIC_STOP.

 2. thread2 runs iscsit_aborted_task and then does __iscsit_free_cmd. It
    then returns from the aborted_task callout and we finish
    target_handle_abort and do:

    target_handle_abort -> transport_cmd_check_stop_to_fabric ->
lio_check_stop_free -> target_put_sess_cmd

    The cmd is now freed.

 3. thread1 now finishes iscsit_release_commands_from_conn and runs
    iscsit_free_cmd while accessing a command we just released.

In __target_check_io_state we check for CMD_T_FABRIC_STOP and set the
CMD_T_ABORTED if the driver is not cleaning up the cmd because of a session
shutdown. However, iscsit_release_commands_from_conn only sets the
CMD_T_FABRIC_STOP and does not check to see if the abort path has claimed
completion ownership of the command.

This adds a check in iscsit_release_commands_from_conn so only the abort or
fabric stop path cleanup the command.

Link: https://lore.kernel.org/r/1605318378-9269-1-git-send-email-michael.christie@oracle.com
Reported-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/target/iscsi/iscsi_target.c