kernel.git/drivers/scsi/hpsa.c, branch linux-3.2.y

hpsa: fix a race in cmd_free/scsi_done

2014-12-14T16:24:01Z

commit 2cc5bfaf854463d9d1aa52091f60110fbf102a96 upstream. When the driver calls scsi_done and after that frees it's internal preallocated memory it can happen that a new job is enqueud before the memory is freed. The allocation fails and the message "cmd_alloc returned NULL" is shown. Patch below fixes it by moving cmd->scsi_done after cmd_free. Signed-off-by: Tomas Henzl Acked-by: Stephen M. Cameron Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings Cc: Masoud Sharbiani

hpsa: fix bad -ENOMEM return value in hpsa_big_passthru_ioctl

2014-09-13T22:41:39Z

commit 0758f4f732b08b6ef07f2e5f735655cf69fea477 upstream. When copy_from_user fails, return -EFAULT, not -ENOMEM Signed-off-by: Stephen M. Cameron Reported-by: Robert Elliott Reviewed-by: Joe Handzik Reviewed-by: Scott Teel Reviewed by: Mike MIller Signed-off-by: Christoph Hellwig Signed-off-by: Ben Hutchings

hpsa: return 0 from driver probe function on success, not 1

2014-01-03T04:33:27Z

commit 88bf6d62db4393fa03a58bada9d746312d5b496f upstream. A return value of 1 is interpreted as an error. See pci_driver. in local_pci_probe(). If you're wondering how this ever could have worked, it's because it used to be the case that only return values less than zero were interpreted as failure. But even in the current kernel if the driver registers its various entry points with the kernel, and then returns a value which is interpreted as failure, those registrations aren't undone, so the driver still mostly works. However, the driver's remove function wouldn't be called on rmmod, and pci power management functions wouldn't work. In the case of Smart Array, since it has a battery backed cache (or else no cache) even if the driver is not shut down properly as long as there is no outstanding i/o, nothing too bad happens, which is why it took so long to notice. Requesting backport to stable because the change to pci-driver.c which requires driver probe functions to return 0 occurred between 2.6.35 and 2.6.36 (the pci power management breakage) and again between 3.7 and 3.8 (pci_dev->driver getting set to NULL in local_pci_probe() preventing driver remove function from being called on rmmod.) Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

hpsa: do not discard scsi status on aborted commands

2014-01-03T04:33:27Z

commit 2e311fbabdc23b7eaec77313dc3b9a151a5407b5 upstream. We inadvertantly discarded the scsi status for aborted commands. For some commands (e.g. reads from tape drives) these can't be retried, and if we discarded the scsi status, the scsi mid layer couldn't notice anything was wrong and the error was not reported. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

hpsa: gen8plus Smart Array IDs

2013-01-03T03:33:54Z

commit fe0c9610bb68dd0aad1017456f5e3c31264d70c2 upstream. Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

hpsa: dial down lockup detection during firmware flash

2012-10-17T02:50:02Z

commit e85c59746957fd6e3595d02cf614370056b5816e upstream. Dial back the aggressiveness of the controller lockup detection thread. Currently it will declare the controller to be locked up if it goes for 10 seconds with no interrupts and no change in the heartbeat register. Dial back this to 30 seconds with no heartbeat change, and also snoop the ioctl path and if a firmware flash command is detected, dial it back further to 4 minutes until the firmware flash command completes. The reason for this is that during the firmware flash operation, the controller apparently doesn't update the heartbeat register as frequently as it is supposed to, and we can get a false positive. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

hpsa: Use LUN reset instead of target reset

2012-10-17T02:48:28Z

commit 21e89afd325849eb38adccf382df16cc895911f9 upstream. It turns out Smart Array logical drives do not support target reset and when the target reset fails, the logical drive will be taken off line. Symptoms look like this: hpsa 0000:03:00.0: Abort request on C1:B0:T0:L0 hpsa 0000:03:00.0: resetting device 1:0:0:0 hpsa 0000:03:00.0: cp ffff880037c56000 is reported invalid (probably means target device no longer present) hpsa 0000:03:00.0: resetting device failed. sd 1:0:0:0: Device offlined - not ready after error recovery sd 1:0:0:0: rejecting I/O to offline device EXT3-fs error (device sdb1): read_block_bitmap: LUN reset is supported though, and is what we should be using. Target reset is also disruptive in shared SAS situations, for example, an external MSA1210m which does support target reset attached to Smart Arrays in multiple hosts -- a target reset from one host is disruptive to other hosts as all LUNs on the target will be reset and will abort all outstanding i/os back to all the attached hosts. So we should use LUN reset, not target reset. Tested this with Smart Array logical drives and with tape drives. Not sure how this bug survived since 2009, except it must be very rare for a Smart Array to require more than 30s to complete a request. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

hpsa: fix handling of protocol error

2012-10-10T02:30:57Z

commit 256d0eaac87da1e993190846064f339f4c7a63f5 upstream. If a command status of CMD_PROTOCOL_ERR is received, this information should be conveyed to the SCSI mid layer, not dropped on the floor. CMD_PROTOCOL_ERR may be received from the Smart Array for any commands destined for an external RAID controller such as a P2000, or commands destined for tape drives or CD/DVD-ROM drives, if for instance a cable is disconnected. This mostly affects multipath configurations, as disconnecting a cable on a non-multipath configuration is not going to do anything good regardless of whether CMD_PROTOCOL_ERR is handled correctly or not. Not handling CMD_PROTOCOL_ERR correctly in a multipath configaration involving external RAID controllers may cause data corruption, so this is quite a serious bug. This bug should not normally cause a problem for direct attached disk storage. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

hpsa: Add IRQF_SHARED back in for the non-MSI(X) interrupt handler

2012-05-30T23:43:53Z

commit 45bcf018d1a4779d592764ef57517c92589d55d7 upstream. IRQF_SHARED is required for older controllers that don't support MSI(X) and which may end up sharing an interrupt. All the controllers hpsa normally supports have MSI(X) capability, but older controllers may be encountered via the hpsa_allow_any=1 module parameter. Also remove deprecated IRQF_DISABLED. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

hpsa: Fix problem with MSA2xxx devices

2012-05-30T23:43:20Z

commit 9bc3711cbb67ac620bf09b4a147cbab45b2c36c0 upstream. Upgraded firmware on Smart Array P7xx (and some others) made them show up as SCSI revision 5 devices and this caused the driver to fail to map MSA2xxx logical drives to the correct bus/target/lun. A symptom of this would be that the target ID of the logical drives as presented by the external storage array is ignored, and all such logical drives are assigned to target zero, differentiated only by LUN. Some multipath software reportedly does not deal well with this behavior, failing to recognize different paths to the same device as such. Signed-off-by: Stephen M. Cameron Signed-off-by: Scott Teel Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings