All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Bogdanov <d.bogdanov@yadro.com>
To: Mike Christie <michael.christie@oracle.com>
Cc: Martin Petersen <martin.petersen@oracle.com>,
	<target-devel@vger.kernel.org>,
	Nick Couchman <nick.e.couchman@gmail.com>,
	<linux-scsi@vger.kernel.org>, <linux@yadro.com>
Subject: Re: [PATCH] target: iscsi: handle abort for WRITE_PENDING cmds
Date: Mon, 18 Jul 2022 11:45:34 +0300	[thread overview]
Message-ID: <20220718084534.GA12544@yadro.com> (raw)
In-Reply-To: <0fc89e77-197b-47e6-f661-5f7f18f6634f@oracle.com>

Hi Mike,

On Thu, Jul 14, 2022 at 11:44:25AM -0500, Mike Christie wrote:
> 
> On 7/13/22 3:42 PM, Dmitry Bogdanov wrote:
> > Sometimes an initiator does not send data for WRITE commands and tries
> > to abort it. The abort hangs waiting for frontend driver completion.
> > iSCSI driver waits for for data and that timeout eventually initiates
> > connection reinstatment. The connection closing releases the commands in
> > the connection, but those aborted commands still did not handle the
> > abort and did not decrease a command ref counter. Because of that the
> > connection reinstatement hangs indefinitely and prevents re-login for
> > that initiator.
> >
> > This patch adds a handling in TCM of the abort for the WRITE_PENDING
> > commands at connection closing moment to make it possible to release
> > them.
> >
> > Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
> > ---
> >  drivers/target/iscsi/iscsi_target.c | 13 ++++++++++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c
> > index e368f038ff5c..27eca5e72f52 100644
> > --- a/drivers/target/iscsi/iscsi_target.c
> > +++ b/drivers/target/iscsi/iscsi_target.c
> > @@ -26,6 +26,7 @@
> >  #include <target/target_core_base.h>
> >  #include <target/target_core_fabric.h>
> >
> > +#include <target/target_core_backend.h>
> >  #include <target/iscsi/iscsi_target_core.h>
> >  #include "iscsi_target_parameters.h"
> >  #include "iscsi_target_seq_pdu_list.h"
> > @@ -4171,7 +4172,8 @@ static void iscsit_release_commands_from_conn(struct iscsit_conn *conn)
> >
> >               if (se_cmd->se_tfo != NULL) {
> >                       spin_lock_irq(&se_cmd->t_state_lock);
> > -                     if (se_cmd->transport_state & CMD_T_ABORTED) {
> > +                     if (se_cmd->t_state != TRANSPORT_WRITE_PENDING &&
> > +                         se_cmd->transport_state & CMD_T_ABORTED) {
> >                               /*
> >                                * LIO's abort path owns the cleanup for this,
> >                                * so put it back on the list and let
> > @@ -4191,8 +4193,13 @@ static void iscsit_release_commands_from_conn(struct iscsit_conn *conn)
> >               list_del_init(&cmd->i_conn_node);
> >
> >               iscsit_increment_maxcmdsn(cmd, sess);
> > -             iscsit_free_cmd(cmd, true);
> > -
> > +             if (cmd->se_cmd.t_state == TRANSPORT_WRITE_PENDING &&
> > +                 cmd->se_cmd.transport_state & CMD_T_ABORTED) {
> > +                     /* handle an abort in TCM */
> > +                     target_complete_cmd(&cmd->se_cmd, SAM_STAT_TASK_ABORTED);
> >
> 
> Will we have an extra ref left on the se_cmd if TAS is used so the se_cmd
> does not get freed?
> 
> For TAS, it looks like we would do:
> 
> - target_handle_abort -> queue_status. This would not do anything because
> before calling iscsit_release_commands_from_conn we have killed the iscsi tx
> thread.
> 
> - target_handle_abort -> transport_cmd_check_stop_to_fabric -> check_stop_free ->
> target_put_sess_cmd.
> 
> iscsi creates the se_cmd with TARGET_SCF_ACK_KREF set so do we have one ref
> left?
Yes, you are right. TAS case is not covered by my patch. But that is
actually another bug (that iSCSI does not complete responses in case of
connection closed).
My patch does not do worse for the that case.
IMHO, TAS + connection closed case has to be addressed in a separate patch.
> 
> For the non TAS case we do two puts:
> 
> target_handle_abort -> SCF_ACK_KREF is set so we do a target_put_sess_cmd here.
> 
> target_handle_abort -> transport_cmd_check_stop_to_fabric -> check_stop_free ->
> target_put_sess_cmd which does a second put.


  reply	other threads:[~2022-07-18  8:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-13 20:42 [PATCH] target: iscsi: handle abort for WRITE_PENDING cmds Dmitry Bogdanov
2022-07-14 16:44 ` Mike Christie
2022-07-18  8:45   ` Dmitry Bogdanov [this message]
2022-07-18 21:22     ` Mike Christie
2022-07-19 16:14       ` Dmitry Bogdanov
2022-07-20  2:31         ` Mike Christie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220718084534.GA12544@yadro.com \
    --to=d.bogdanov@yadro.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux@yadro.com \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --cc=nick.e.couchman@gmail.com \
    --cc=target-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.