From patchwork Wed Nov 29 16:58:30 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hannes Reinecke X-Patchwork-Id: 13473232 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C4401DDFA for ; Wed, 29 Nov 2023 16:58:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c7a2kesU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D2F7C433C8; Wed, 29 Nov 2023 16:58:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701277115; bh=tdKTLW9MjVNyXmF52ilkOBStKcI32S26AWAl0daQqG0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c7a2kesUXHeP3dygqbPbR5fH1rKvi2NZbwzBepzjisn3Q4caEWFP4KjslFD8swKZ8 xvF3tXyzTrCRF6TWQe/RyRfD2UbF5oEfg0xVzEr9psAQqgLqKhojqUJGqG5TrVO+w4 kIl7uIxWAlYdToQnsiRbYlxrxz4bbU5wMJBirg7saN3Rja3XJK1qe2Tu4BnG3Kfjff 1LZ2unXg36srcmW1xVCC14h39BzOGHCU/1meLu8lGvcw9CCCuEt853DBCKDmd9HuDk YLtJhaU46pxnFcXV55oafs5gzDFIEAbfBsvhpRrXl5Yy4wSRaCp6+32ITkaWcDGC5z YTgN3Z4efKZgA== From: hare@kernel.org To: "Martin K. Petersen" Cc: James Bottomley , Christoph Hellwig , linux-scsi@vger.kernel.org, Hannes Reinecke Subject: [PATCH 1/3] libfc: don't schedule abort twice Date: Wed, 29 Nov 2023 17:58:30 +0100 Message-Id: <20231129165832.224100-2-hare@kernel.org> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20231129165832.224100-1-hare@kernel.org> References: <20231129165832.224100-1-hare@kernel.org> Precedence: bulk X-Mailing-List: linux-scsi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Hannes Reinecke 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 Reviewed-by: Christoph Hellwig --- 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); } /** From patchwork Wed Nov 29 16:58:31 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hannes Reinecke X-Patchwork-Id: 13473233 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED78C210E2 for ; Wed, 29 Nov 2023 16:58:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CiifQz5u" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E684C433C9; Wed, 29 Nov 2023 16:58:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701277117; bh=TD8HdJRqayfG1gI4lBUHfilG6MKifdvps7YI2WGPLHo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CiifQz5umjmuq1dTVo5vGDVHDx4Mjp2l0RXlCC3y6YPaa69jxitqFA6XV8zSOcunx STm8Q0ta2J/0U96WmV6I5YoavehVl1F5/8PixdEmh9Riswjq5oHo6Hu74UdM/zEe4n WDAZmbHYGKE/XMjgZrpjCoo+Lgvwf42+GDrUmLhnzcYTeJvHc5Tws6ihUa34CEufbL NzmR7ekPm4JVGn1cKYBF6xdsprXl4J59Z+MhrRcwnwKWoHD36E8zuJkvZo5DPL8RNC 98OSShXIVsWy6O4RPw0FZdkt/PZXNzPPWYL22q5DOlF3micOh4SJnOute4bBpl84ZZ DnUxkWcYBLwWg== From: hare@kernel.org To: "Martin K. Petersen" Cc: James Bottomley , Christoph Hellwig , linux-scsi@vger.kernel.org, Hannes Reinecke Subject: [PATCH 2/3] libfc: Fixup timeout error in fc_fcp_rec_error() Date: Wed, 29 Nov 2023 17:58:31 +0100 Message-Id: <20231129165832.224100-3-hare@kernel.org> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20231129165832.224100-1-hare@kernel.org> References: <20231129165832.224100-1-hare@kernel.org> Precedence: bulk X-Mailing-List: linux-scsi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Hannes Reinecke We should set the status to FC_TIMED_OUT when a timeout error is passed to fc_fcp_rec_error(). Signed-off-by: Hannes Reinecke Reviewed-by: Christoph Hellwig --- drivers/scsi/libfc/fc_fcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c index 3f189cedf6db..05be0810b5e3 100644 --- a/drivers/scsi/libfc/fc_fcp.c +++ b/drivers/scsi/libfc/fc_fcp.c @@ -1676,7 +1676,7 @@ static void fc_fcp_rec_error(struct fc_fcp_pkt *fsp, struct fc_frame *fp) if (fsp->recov_retry++ < FC_MAX_RECOV_RETRY) fc_fcp_rec(fsp); else - fc_fcp_recovery(fsp, FC_ERROR); + fc_fcp_recovery(fsp, FC_TIMED_OUT); break; } fc_fcp_unlock_pkt(fsp); From patchwork Wed Nov 29 16:58:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hannes Reinecke X-Patchwork-Id: 13473234 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9061A210E2 for ; Wed, 29 Nov 2023 16:58:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hkKaGBe1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD7A1C433C8; Wed, 29 Nov 2023 16:58:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701277119; bh=DJVXUbcukE10rkfMlJhT2I5u7DfVRwTczDIe5/khTZM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hkKaGBe1CVrZlmDMTgLMXAXuFYd3u+lKKs7CYsLFD636Ivks4OrXebgRXx9FNxH/1 OBdKzSV7yNnVW7kEfdTbuwFlK7Wg1IbZxg0b25NRQUgp3f1f6hCXL4CGRzO7W25xx9 JDITFescfYyRt947JULeF2fhdr86t5EYby/zNNuB2aRlrJgJHqF7Q40mJ/oMIV+ezx DgcMqs+DLMGUaVPmjTiTSRjoiuo1FuN+03lvnNsTwiNKG4Rm6jQSnzqpyShpMU91/G U8WNo7ah1eFges15e5yXTT3laHFNrD7C8Ir6qh+aHHVfiqh73QfGQCnxAWYkeWvsY7 olF5Z3oZBf13g== From: hare@kernel.org To: "Martin K. Petersen" Cc: James Bottomley , Christoph Hellwig , linux-scsi@vger.kernel.org, Hannes Reinecke Subject: [PATCH 3/3] libfc: map FC_TIMED_OUT to DID_TIME_OUT Date: Wed, 29 Nov 2023 17:58:32 +0100 Message-Id: <20231129165832.224100-4-hare@kernel.org> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20231129165832.224100-1-hare@kernel.org> References: <20231129165832.224100-1-hare@kernel.org> Precedence: bulk X-Mailing-List: linux-scsi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Hannes Reinecke When an exchange is completed with FC_TIMED_OUT we should map it to DID_TIME_OUT to inform the SCSI midlayer that this was a command timeout; DID_BUS_BUSY implies that the command was never sent which is not the case here. Signed-off-by: Hannes Reinecke Reviewed-by: Christoph Hellwig --- drivers/scsi/libfc/fc_fcp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c index 05be0810b5e3..80be3a936d92 100644 --- a/drivers/scsi/libfc/fc_fcp.c +++ b/drivers/scsi/libfc/fc_fcp.c @@ -2062,9 +2062,9 @@ static void fc_io_compl(struct fc_fcp_pkt *fsp) sc_cmd->result = (DID_PARITY << 16); break; case FC_TIMED_OUT: - FC_FCP_DBG(fsp, "Returning DID_BUS_BUSY to scsi-ml " + FC_FCP_DBG(fsp, "Returning DID_TIME_OUT to scsi-ml " "due to FC_TIMED_OUT\n"); - sc_cmd->result = (DID_BUS_BUSY << 16) | fsp->io_status; + sc_cmd->result = (DID_TIME_OUT << 16); break; default: FC_FCP_DBG(fsp, "Returning DID_ERROR to scsi-ml "