All of lore.kernel.org
 help / color / mirror / Atom feed
From: hare@kernel.org
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: James Bottomley <james.bottomley@hansenpartnership.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-scsi@vger.kernel.org, Hannes Reinecke <hare@suse.de>
Subject: [PATCH 1/3] libfc: don't schedule abort twice
Date: Wed, 29 Nov 2023 17:58:30 +0100	[thread overview]
Message-ID: <20231129165832.224100-2-hare@kernel.org> (raw)
In-Reply-To: <20231129165832.224100-1-hare@kernel.org>

From: Hannes Reinecke <hare@suse.de>

The current FC error recovery is sending up to three REC (recovery)
frames in 10 second intervals, and as a final step sending an ABTS
after 30 seconds for the command itself.
Unfortunately sending an ABTS is also the action for the SCSI
abort handler, and the default timeout for scsi commands is also
30 seconds. This causes two ABTS to be scheduled, with the libfc
one slightly earlier. The ABTS scheduled by SCSI EH then sees the
command to be already aborted, and will always return with a 'GOOD'
status irrespective on the actual result from the first ABTS.
This causes the SCSI EH abort handler to always succeed, and
SCSI EH never to be engaged.
Fix this by not issuing an ABTS when a SCSI command is present
for the exchange, but rather wait for the abort scheduled from
SCSI EH.
And warn if an abort is already scheduled to avoid similar errors
in the future.

Signed-off-by: Hannes Reinecke <hare@suse.de>
---
 drivers/scsi/libfc/fc_fcp.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c
index 945adca5e72f..3f189cedf6db 100644
--- a/drivers/scsi/libfc/fc_fcp.c
+++ b/drivers/scsi/libfc/fc_fcp.c
@@ -265,6 +265,11 @@ static int fc_fcp_send_abort(struct fc_fcp_pkt *fsp)
 	if (!fsp->seq_ptr)
 		return -EINVAL;
 
+	if (fsp->state & FC_SRB_ABORT_PENDING) {
+		FC_FCP_DBG(fsp, "abort already pending\n");
+		return -EBUSY;
+	}
+
 	this_cpu_inc(fsp->lp->stats->FcpPktAborts);
 
 	fsp->state |= FC_SRB_ABORT_PENDING;
@@ -1690,11 +1695,12 @@ static void fc_fcp_recovery(struct fc_fcp_pkt *fsp, u8 code)
 	fsp->status_code = code;
 	fsp->cdb_status = 0;
 	fsp->io_status = 0;
-	/*
-	 * if this fails then we let the scsi command timer fire and
-	 * scsi-ml escalate.
-	 */
-	fc_fcp_send_abort(fsp);
+	if (!fsp->cmd)
+		/*
+		 * Only abort non-scsi commands; otherwise let the
+		 * scsi command timer fire and scsi-ml escalate.
+		 */
+		fc_fcp_send_abort(fsp);
 }
 
 /**
-- 
2.35.3


  reply	other threads:[~2023-11-29 16:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 16:58 [PATCH 0/3] libfc: fixup command abort handling hare
2023-11-29 16:58 ` hare [this message]
2023-12-04  8:04   ` [PATCH 1/3] libfc: don't schedule abort twice Christoph Hellwig
2023-11-29 16:58 ` [PATCH 2/3] libfc: Fixup timeout error in fc_fcp_rec_error() hare
2023-12-04  8:04   ` Christoph Hellwig
2023-11-29 16:58 ` [PATCH 3/3] libfc: map FC_TIMED_OUT to DID_TIME_OUT hare
2023-12-04  8:04   ` Christoph Hellwig
2023-12-14  4:29 ` [PATCH 0/3] libfc: fixup command abort handling Martin K. Petersen

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=20231129165832.224100-2-hare@kernel.org \
    --to=hare@kernel.org \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /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.