From: James Bottomley <jejb@linux.vnet.ibm.com>
To: David Miller <davem@davemloft.net>, Bart.VanAssche@sandisk.com
Cc: hch@infradead.org, jbaron@akamai.com,
linux-kernel@vger.kernel.org, sagi@grimberg.me,
sathya.prakash@broadcom.com,
suganath-prabu.subramani@broadcom.com,
martin.petersen@oracle.com, hare@suse.de,
linux-scsi@vger.kernel.org, hch@lst.de,
Sreekanth.Reddy@broadcom.com, chaitra.basappa@broadcom.com,
dledford@redhat.com
Subject: Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands
Date: Sun, 01 Jan 2017 09:39:24 -0800 [thread overview]
Message-ID: <1483292364.2345.5.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170101.113311.417107391370623850.davem@davemloft.net>
On Sun, 2017-01-01 at 11:33 -0500, David Miller wrote:
> From: Bart Van Assche <Bart.VanAssche@sandisk.com>
> Date: Sun, 1 Jan 2017 14:22:11 +0000
>
> > My recommendation is to revert commit 18f6084a989b ("scsi: mpt3sas: Fix
> > secure erase premature termination"). Since the mpt3sas driver uses the
> > single-queue approach and since the SCSI core unlocks the block layer
> > request queue lock before the .queuecommand callback function is called,
> > multiple threads can execute that callback function (scsih_qcmd() in this
> > case) simultaneously. This means that using scsi_internal_device_block()
> > from inside .queuecommand to serialize SCSI command execution is wrong.
>
> But this causes a regression for the thing being fixed by that
> commit.
Right, we don't do that; that's why I didn't list it as one of the
options.
> Why don't we figure out what that semantics that commit was trying to
> achieve and implement that properly?
Now that I look at the reviews, each of the reviewers said what the
correct thing to do was: return SAM_STAT_BUSY if SATL commands are
outstanding like the spec says. You all get negative brownie points
for not insisting on a rework.
Does this patch (compile tested only) fix the problems for everyone?
James
---
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 394fe13..0983a65 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -393,6 +393,7 @@ struct MPT3SAS_TARGET {
* @eedp_enable: eedp support enable bit
* @eedp_type: 0(type_1), 1(type_2), 2(type_3)
* @eedp_block_length: block size
+ * @ata_command_pending: SATL passthrough outstanding for device
*/
struct MPT3SAS_DEVICE {
struct MPT3SAS_TARGET *sas_target;
@@ -404,6 +405,17 @@ struct MPT3SAS_DEVICE {
u8 ignore_delay_remove;
/* Iopriority Command Handling */
u8 ncq_prio_enable;
+ /*
+ * Bug workaround for SATL handling: the mpt2/3sas firmware
+ * doesn't return BUSY or TASK_SET_FULL for subsequent
+ * commands while a SATL pass through is in operation as the
+ * spec requires, it simply does nothing with them until the
+ * pass through completes, causing them possibly to timeout if
+ * the passthrough is a long executing command (like format or
+ * secure erase). This variable allows us to do the right
+ * thing while a SATL command is pending.
+ */
+ u8 ata_command_pending;
};
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index b5c966e..1446a0a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3899,9 +3899,12 @@ _scsih_temp_threshold_events(struct MPT3SAS_ADAPTER *ioc,
}
}
-static inline bool ata_12_16_cmd(struct scsi_cmnd *scmd)
+static void set_satl_pending(struct scsi_cmnd *scmd, bool pending)
{
- return (scmd->cmnd[0] == ATA_12 || scmd->cmnd[0] == ATA_16);
+ struct MPT3SAS_DEVICE *priv = scmd->device->hostdata;
+
+ if (scmd->cmnd[0] == ATA_12 || scmd->cmnd[0] == ATA_16)
+ priv->ata_command_pending = pending;
}
/**
@@ -3925,9 +3928,7 @@ _scsih_flush_running_cmds(struct MPT3SAS_ADAPTER *ioc)
if (!scmd)
continue;
count++;
- if (ata_12_16_cmd(scmd))
- scsi_internal_device_unblock(scmd->device,
- SDEV_RUNNING);
+ set_satl_pending(scmd, false);
mpt3sas_base_free_smid(ioc, smid);
scsi_dma_unmap(scmd);
if (ioc->pci_error_recovery)
@@ -4063,13 +4064,6 @@ scsih_qcmd(struct Scsi_Host *shost, struct scsi_cmnd *scmd)
if (ioc->logging_level & MPT_DEBUG_SCSI)
scsi_print_command(scmd);
- /*
- * Lock the device for any subsequent command until command is
- * done.
- */
- if (ata_12_16_cmd(scmd))
- scsi_internal_device_block(scmd->device);
-
sas_device_priv_data = scmd->device->hostdata;
if (!sas_device_priv_data || !sas_device_priv_data->sas_target) {
scmd->result = DID_NO_CONNECT << 16;
@@ -4083,6 +4077,16 @@ scsih_qcmd(struct Scsi_Host *shost, struct scsi_cmnd *scmd)
return 0;
}
+ /*
+ * Bug work around for firmware SATL handling
+ */
+ if (sas_device_priv_data->ata_command_pending) {
+ scmd->result = SAM_STAT_BUSY;
+ scmd->scsi_done(scmd);
+ return 0;
+ }
+ set_satl_pending(scmd, true);
+
sas_target_priv_data = sas_device_priv_data->sas_target;
/* invalid device handle */
@@ -4650,8 +4654,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 msix_index, u32 reply)
if (scmd == NULL)
return 1;
- if (ata_12_16_cmd(scmd))
- scsi_internal_device_unblock(scmd->device, SDEV_RUNNING);
+ set_satl_pending(scmd, false);
mpi_request = mpt3sas_base_get_msg_frame(ioc, smid);
next prev parent reply other threads:[~2017-01-01 17:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-29 4:30 [PATCH] scsi: mpt3sas: fix hang on ata passthru commands Jason Baron
2016-12-29 8:02 ` Christoph Hellwig
2016-12-29 16:02 ` Jason Baron
2016-12-31 23:19 ` James Bottomley
2017-01-01 14:22 ` Bart Van Assche
2017-01-01 15:30 ` Jason Baron
2017-01-01 16:33 ` David Miller
2017-01-01 17:39 ` James Bottomley [this message]
2017-01-03 20:46 ` Jason Baron
2017-01-15 17:01 ` James Bottomley
2017-01-16 16:20 ` Bart Van Assche
2017-01-06 1:59 ` Martin K. Petersen
2017-01-06 15:46 ` Sreekanth Reddy
2017-01-10 4:50 ` Martin K. Petersen
2017-01-16 20:01 ` James Bottomley
2017-01-16 21:01 ` Martin K. Petersen
2017-01-17 9:20 ` Ingo Molnar
2017-01-17 14:13 ` Sreekanth Reddy
2017-01-17 14:15 ` Christoph Hellwig
2017-01-17 19:44 ` Martin K. Petersen
2017-01-17 14:44 ` James Bottomley
2016-12-29 16:16 ` David Miller
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=1483292364.2345.5.camel@linux.vnet.ibm.com \
--to=jejb@linux.vnet.ibm.com \
--cc=Bart.VanAssche@sandisk.com \
--cc=Sreekanth.Reddy@broadcom.com \
--cc=chaitra.basappa@broadcom.com \
--cc=davem@davemloft.net \
--cc=dledford@redhat.com \
--cc=hare@suse.de \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=jbaron@akamai.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sagi@grimberg.me \
--cc=sathya.prakash@broadcom.com \
--cc=suganath-prabu.subramani@broadcom.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).