mpt2sas: Added module parameter 'unblock_io' to unblock IO's during disk addition

During hot-plugging of a disk(having a flaky link) the disk addition stops and any further disk addition or removal doesn't happen on that controller.

This is because, when driver receives DELAY_NOT_RESPONDING for a disk when it is undergoing addition in the SCSI Mid layer, the driver would block the I/O to that disk resulting in a deadlock. i.e the disk addition work couldn't be completed
as it can't send any I/O to the disk as I/Os are blocked. Any device removal (TARGET_NOT_RESPONDING) or link update(RC_PHY_CHANGED) couldn't be processed as they are in the queue
to get processed after disk addition.

Description of Change:
To handle such cases, unblock the I/Os to the disk in ISR context if the disk is undergoing addition. The I/Os would get unblocked only if the driver receives RC_PHY_CHANGED reason code when the device addition is within the SAS Transport layer.

An module parameter 'unblock_io' is introduced which needs to be set to have this functionality enabled. By default this functionality is disabled.

---
 drivers/scsi/mpt2sas/mpt2sas_base.h      |    3 +
 drivers/scsi/mpt2sas/mpt2sas_scsih.c     |   67 ++++++++++++++++++++++++++---
 drivers/scsi/mpt2sas/mpt2sas_transport.c |   13 ++++++
 3 files changed, 76 insertions(+), 7 deletions(-)

index 32181a6..7de7ba4 100644
@@ -356,6 +356,8 @@ struct _internal_cmd {
  * @phy: phy identifier provided in sas device page 0
  * @responding: used in _scsih_sas_device_mark_responding
  * @pfa_led_on: flag for PFA LED status
+ * @pend_sas_rphy_add: flag to check if device is in sas_rphy_add()
+ *			addition routine
  */
 struct _sas_device {
 	struct list_head list;

@@ -375,6 +377,7 @@ struct _sas_device {
 	u8	phy;
 	u8	responding;
 	u8	pfa_led_on;
+	u8	pend_sas_rphy_add;
 };
 
 /**

index 0d1d064..f09f5f3 100644
@@ -654,6 +654,7 @@ mpt2sas_transport_port_add(struct MPT2SAS_ADAPTER *ioc, u16 handle,
 	unsigned long flags;
 	struct _sas_node *sas_node;
 	struct sas_rphy *rphy;
+	struct _sas_device *sas_device = NULL;
 	int i;
 	struct sas_port *port;
 

@@ -736,10 +737,22 @@ mpt2sas_transport_port_add(struct MPT2SAS_ADAPTER *ioc, u16 handle,
 		    mpt2sas_port->remote_identify.device_type);
 
 	rphy->identify = mpt2sas_port->remote_identify;
+	if (mpt2sas_port->remote_identify.device_type == SAS_END_DEVICE) {
+		sas_device = mpt2sas_scsih_sas_device_find_by_sas_address(ioc,
+		    mpt2sas_port->remote_identify.sas_address);
+		if (!sas_device) {
+			printk(MPT2SAS_ERR_FMT "failure at %s:%d/%s()!\n",
+			    ioc->name, __FILE__, __LINE__, __func__);
+			goto out_fail;
+		}
+		sas_device->pend_sas_rphy_add = 1;
+	}
 	if ((sas_rphy_add(rphy))) {
 		printk(MPT2SAS_ERR_FMT "failure at %s:%d/%s()!\n",
 		    ioc->name, __FILE__, __LINE__, __func__);
 	}
+	if (mpt2sas_port->remote_identify.device_type == SAS_END_DEVICE)
+		sas_device->pend_sas_rphy_add = 0;
 	if ((ioc->logging_level & MPT_DEBUG_TRANSPORT))
 		dev_printk(KERN_INFO, &rphy->dev, "add: handle(0x%04x), "
 		    "sas_addr(0x%016llx)\n", handle,

1.7.1

Sreekanth> This is because, when driver receives DELAY_NOT_RESPONDING Sreekanth> for a disk when it is undergoing addition in the SCSI Mid Sreekanth> layer, the driver would block the I/O to that disk resulting Sreekanth> in a deadlock. i.e the disk addition work couldn't be Sreekanth> completed as it can't send any I/O to the disk as I/Os are Sreekanth> blocked. Any device removal (TARGET_NOT_RESPONDING) or link Sreekanth> update(RC_PHY_CHANGED) couldn't be processed as they are in Sreekanth> the queue to get processed after disk addition.

Sreekanth> An module parameter 'unblock_io' is introduced which needs to Sreekanth> be set to have this functionality enabled. By default this Sreekanth> functionality is disabled.

This really sounds like a scenario you should be able to handle in general (without special "don't-be-broken" module parameters).

Also, shouldn't your internal task management be able to deal with this? Why does the sdev's state during probe affect your ability to make forward progress?

Martin K. Petersen	Oracle Linux Engineering