On Mon, 2018-06-11 at 13:32 -0500, Mike Christie wrote:
> I think the patch looks ok bug/behavior wise. I was just wondering why
> there is the difference between iscsi and the rest of the target drivers.
>
> It looks like with this patch iscsi is the only driver that can do a
> transport_generic_free_cmd call with wait_for_tasks=true when something
> like a iscsi connection is stopped, so it is the only one that now uses
> the CMD_T_FABRIC_STOP bit and all the related code.
>
> It looks like all other drivers do something like you mention above and
> do a target_sess_cmd_list_set_waiting+target_wait_for_sess_cmds sequence.
>
> Is the only reason for this due to the struct se_session mapping to a
> struct iscsi_session and we might need to wait on commands in a specific
> connection in a session or was there some other race/TMF type of issue?
Hello Mike,
This is because the LIO iSCSI target driver uses a weird combination of
reference counting and synchronous command management. For all LIO target
drivers except the iSCSI target driver it is fine to decrease the command
reference count and not to worry about when exactly the command will be
freed. The iSCSI target driver however is special: there is code in the
iSCSI target driver that assumes that all tasks have finished after
iscsit_free_cmd() has returned. An example is the code in
iscsit_close_connection(): after iscsit_release_commands_from_conn() has
returned, iscsit_free_queue_reqs_for_conn() is called. It may be possible
to rework the iSCSI target driver such that it becomes more similar to the
other target drivers. However, making that change would require more time
than I had available.
Bart.
��.n��������+%������w��{.n����j� ����{ay� ʇڙ���f���h������_�(�階�ݢj"��������G����?���&��
