Hi Zhu & Co,
Just to close the loop on this earlier patch. Comments below.
On Wed, 2016-08-31 at 17:49 +0800, Zhu Lingshan wrote:
> This fixed an issue where IO stress testing on
> top of OCFS2 over an iSCSI target. Missed a
> complet operation caused the target hung,
> requiring a reboot. Also moved the complete
> operation out of the conditionals.
>
> Signed-off-by: Zhu Lingshan <lszhu@xxxxxxxx>
> ---
> drivers/target/iscsi/iscsi_target.c | 13 +++++--------
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c
> index 50f3d3a..4fdde4e 100644
> --- a/drivers/target/iscsi/iscsi_target.c
> +++ b/drivers/target/iscsi/iscsi_target.c
> @@ -4279,16 +4279,12 @@ int iscsit_close_connection(
> spin_unlock_bh(&sess->conn_lock);
> iscsit_close_session(sess);
>
> - return 0;
> } else if (atomic_read(&sess->session_logout)) {
> pr_debug("Moving to TARG_SESS_STATE_FREE.\n");
> sess->session_state = TARG_SESS_STATE_FREE;
> spin_unlock_bh(&sess->conn_lock);
>
> - if (atomic_read(&sess->sleep_on_sess_wait_comp))
> - complete(&sess->session_wait_comp);
>
> - return 0;
> } else {
> pr_debug("Moving to TARG_SESS_STATE_FAILED.\n");
> sess->session_state = TARG_SESS_STATE_FAILED;
> @@ -4299,11 +4295,12 @@ int iscsit_close_connection(
> } else
> spin_unlock_bh(&sess->conn_lock);
>
> - if (atomic_read(&sess->sleep_on_sess_wait_comp))
> - complete(&sess->session_wait_comp);
> -
> - return 0;
> }
> + if (atomic_read(&sess->sleep_on_sess_wait_comp))
> + complete(&sess->session_wait_comp);
> +
> + return 0;
> +
> }
>
The atomic_read + complete here must not be called for the
iscsit_close_session() case, because it's already freeing *sess memory.
The call to iscsit_close_session() above in iscsit_close_connection()
means no other callers have invoked session shutdown explicitly, and
it's safe to release sess resources directly.
When a process is waiting on ->session_wait_comp from another context it
means session shutdown (say via session reinstatement for example) has
been explicitly invoked, and is waiting for iscsi-session shutdown to
complete, once all previous I/O completes back to target-core.
Note that if iscsit_close_connection() is blocking for extended periods
waiting for target-core iscsi_cmd->se_cmd descriptors to complete,
either the backend is taking a long time (or leaking) I/O completions
all together, or there is a target-core bug wrt reference counting for
se_cmd->cmd_kref to reach zero.
That said, I assume this patch was an attempt to fix the missing
SCF_ACK_KREF assignment regression in v4.1+, that leaks se_cmd->cmd_kref
by +1 during ABORT_TASK + iscsi-target session reinstatement scenarios
here:
http://www.spinics.net/lists/target-devel/msg13530.html
Can you verify your earlier reproduction case with the above patch on
stock v4.x mainline code..?
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
