summaryrefslogtreecommitdiff
path: root/drivers/scsi
AgeCommit message (Collapse)Author
2014-08-07scsi: handle flush errors properlyJames Bottomley
commit 89fb4cd1f717a871ef79fa7debbe840e3225cd54 upstream. Flush commands don't transfer data and thus need to be special cased in the I/O completion handler so that we can propagate errors to the block layer and filesystem. Signed-off-by: James Bottomley <JBottomley@Parallels.com> Reported-by: Steven Haber <steven@qumulo.com> Tested-by: Steven Haber <steven@qumulo.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-09sym53c8xx_2: Set DID_REQUEUE return code when aborting squeueMikulas Patocka
commit fd1232b214af43a973443aec6a2808f16ee5bf70 upstream. This patch fixes I/O errors with the sym53c8xx_2 driver when the disk returns QUEUE FULL status. When the controller encounters an error (including QUEUE FULL or BUSY status), it aborts all not yet submitted requests in the function sym_dequeue_from_squeue. This function aborts them with DID_SOFT_ERROR. If the disk has full tag queue, the request that caused the overflow is aborted with QUEUE FULL status (and the scsi midlayer properly retries it until it is accepted by the disk), but the sym53c8xx_2 driver aborts the following requests with DID_SOFT_ERROR --- for them, the midlayer does just a few retries and then signals the error up to sd. The result is that disk returning QUEUE FULL causes request failures. The error was reproduced on 53c895 with COMPAQ BD03685A24 disk (rebranded ST336607LC) with command queue 48 or 64 tags. The disk has 64 tags, but under some access patterns it return QUEUE FULL when there are less than 64 pending tags. The SCSI specification allows returning QUEUE FULL anytime and it is up to the host to retry. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: Matthew Wilcox <matthew@wil.cx> Cc: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-09virtio-scsi: fix various bad behavior on aborted requestsPaolo Bonzini
commit 8faeb529b2dabb9df691d614dda18910a43d05c9 upstream. Even though the virtio-scsi spec guarantees that all requests related to the TMF will have been completed by the time the TMF itself completes, the request queue's callback might not have run yet. This causes requests to be completed more than once, and as a result triggers a variety of BUGs or oopses. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Venkatesh Srinivas <venkateshs@google.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-09virtio-scsi: avoid cancelling uninitialized work itemsPaolo Bonzini
commit cdda0e5acbb78f7b777049f8c27899e5c5bb368f upstream. Calling the workqueue interface on uninitialized work items isn't a good idea even if they're zeroed. It's not failing catastrophically only through happy accidents. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-09ibmvscsi: Add memory barriers for send / receiveBrian King
commit 7114aae02742d6b5c5a0d39a41deb61d415d3717 upstream. Add a memory barrier prior to sending a new command to the VIOS to ensure the VIOS does not receive stale data in the command buffer. Also add a memory barrier when processing the CRQ for completed commands. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Acked-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-09ibmvscsi: Abort init sequence during error recoveryBrian King
commit 9ee755974bea2f9880e517ec985dc9dede1b3a36 upstream. If a CRQ reset is triggered for some reason while in the middle of performing VSCSI adapter initialization, we don't want to call the done function for the initialization MAD commands as this will only result in two threads attempting initialization at the same time, resulting in failures. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Acked-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-26net: Use netlink_ns_capable to verify the permisions of netlink messagesEric W. Biederman
[ Upstream commit 90f62cf30a78721641e08737bda787552428061e ] It is possible by passing a netlink socket to a more privileged executable and then to fool that executable into writing to the socket data that happens to be valid netlink message to do something that privileged executable did not intend to do. To keep this from happening replace bare capable and ns_capable calls with netlink_capable, netlink_net_calls and netlink_ns_capable calls. Which act the same as the previous calls except they verify that the opener of the socket had the desired permissions as well. Reported-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-16SCSI: megaraid: Use resource_size_t for PCI resources, not longBen Collins
commit 11f8a7b31f2140b0dc164bb484281235ffbe51d3 upstream. The assumption that sizeof(long) >= sizeof(resource_size_t) can lead to truncation of the PCI resource address, meaning this driver didn't work on 32-bit systems with 64-bit PCI adressing ranges. Signed-off-by: Ben Collins <ben.c@servergy.com> Acked-by: Sumit Saxena <sumit.saxena@lsi.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-30SCSI: megaraid: missing bounds check in mimd_to_kioc()Dan Carpenter
commit 3de2260140417759c669d391613d583baf03b0cf upstream. pthru32->dataxferlen comes from the user so we need to check that it's not too large so we don't overflow the buffer. Reported-by: Nico Golde <nico@ngolde.de> Reported-by: Fabian Yamaguchi <fabs@goesec.de> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Sumit Saxena <sumit.saxena@lsi.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-30SCSI: dual scan thread bug fixJames Bottomley
commit f2495e228fce9f9cec84367547813cbb0d6db15a upstream. In the highly unusual case where two threads are running concurrently through the scanning code scanning the same target, we run into the situation where one may allocate the target while the other is still using it. In this case, because the reap checks for STARGET_CREATED and kills the target without reference counting, the second thread will do the wrong thing on reap. Fix this by reference counting even creates and doing the STARGET_CREATED check in the final put. Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-30scsi: fix our current target reap infrastructureJames Bottomley
commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream. This patch eliminates the reap_ref and replaces it with a proper kref. On last put of this kref, the target is removed from visibility in sysfs. The final call to scsi_target_reap() for the device is done from __scsi_remove_device() and only if the device was made visible. This ensures that the target disappears as soon as the last device is gone rather than waiting until final release of the device (which is often too long). Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13mpt2sas: Don't disable device twice at suspend.Tyler Stachecki
commit af61e27c3f77c7623b5335590ae24b6a5c323e22 upstream. On suspend, _scsih_suspend calls mpt2sas_base_free_resources, which in turn calls pci_disable_device if the device is enabled prior to suspending. However, _scsih_suspend also calls pci_disable_device itself. Thus, in the event that the device is enabled prior to suspending, pci_disable_device will be called twice. This patch removes the duplicate call to pci_disable_device in _scsi_suspend as it is both unnecessary and results in a kernel oops. Signed-off-by: Tyler Stachecki <tstache1@binghamton.edu> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13virtio-scsi: Skip setting affinity on uninitialized vqFam Zheng
commit 0c8482ac92db5ac15792caf23b7f7df9e4f48ae1 upstream. virtscsi_init calls virtscsi_remove_vqs on err, even before initializing the vqs. The latter calls virtscsi_set_affinity, so let's check the pointer there before setting affinity on it. This fixes a panic when setting device's num_queues=2 on RHEL 6.5: qemu-system-x86_64 ... \ -device virtio-scsi-pci,id=scsi0,addr=0x13,...,num_queues=2 \ -drive file=/stor/vm/dummy.raw,id=drive-scsi-disk,... \ -device scsi-hd,drive=drive-scsi-disk,... [ 0.354734] scsi0 : Virtio SCSI HBA [ 0.379504] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 0.380141] IP: [<ffffffff814741ef>] __virtscsi_set_affinity+0x4f/0x120 [ 0.380141] PGD 0 [ 0.380141] Oops: 0000 [#1] SMP [ 0.380141] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0+ #5 [ 0.380141] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007 [ 0.380141] task: ffff88003c9f0000 ti: ffff88003c9f8000 task.ti: ffff88003c9f8000 [ 0.380141] RIP: 0010:[<ffffffff814741ef>] [<ffffffff814741ef>] __virtscsi_set_affinity+0x4f/0x120 [ 0.380141] RSP: 0000:ffff88003c9f9c08 EFLAGS: 00010256 [ 0.380141] RAX: 0000000000000000 RBX: ffff88003c3a9d40 RCX: 0000000000001070 [ 0.380141] RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 [ 0.380141] RBP: ffff88003c9f9c28 R08: 00000000000136c0 R09: ffff88003c801c00 [ 0.380141] R10: ffffffff81475229 R11: 0000000000000008 R12: 0000000000000000 [ 0.380141] R13: ffffffff81cc7ca8 R14: ffff88003cac3d40 R15: ffff88003cac37a0 [ 0.380141] FS: 0000000000000000(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000 [ 0.380141] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 0.380141] CR2: 0000000000000020 CR3: 0000000001c0e000 CR4: 00000000000006f0 [ 0.380141] Stack: [ 0.380141] ffff88003c3a9d40 0000000000000000 ffff88003cac3d80 ffff88003cac3d40 [ 0.380141] ffff88003c9f9c48 ffffffff814742e8 ffff88003c26d000 ffff88003c26d000 [ 0.380141] ffff88003c9f9c68 ffffffff81474321 ffff88003c26d000 ffff88003c3a9d40 [ 0.380141] Call Trace: [ 0.380141] [<ffffffff814742e8>] virtscsi_set_affinity+0x28/0x40 [ 0.380141] [<ffffffff81474321>] virtscsi_remove_vqs+0x21/0x50 [ 0.380141] [<ffffffff81475231>] virtscsi_init+0x91/0x240 [ 0.380141] [<ffffffff81365290>] ? vp_get+0x50/0x70 [ 0.380141] [<ffffffff81475544>] virtscsi_probe+0xf4/0x280 [ 0.380141] [<ffffffff81363ea5>] virtio_dev_probe+0xe5/0x140 [ 0.380141] [<ffffffff8144c669>] driver_probe_device+0x89/0x230 [ 0.380141] [<ffffffff8144c8ab>] __driver_attach+0x9b/0xa0 [ 0.380141] [<ffffffff8144c810>] ? driver_probe_device+0x230/0x230 [ 0.380141] [<ffffffff8144c810>] ? driver_probe_device+0x230/0x230 [ 0.380141] [<ffffffff8144ac1c>] bus_for_each_dev+0x8c/0xb0 [ 0.380141] [<ffffffff8144c499>] driver_attach+0x19/0x20 [ 0.380141] [<ffffffff8144bf28>] bus_add_driver+0x198/0x220 [ 0.380141] [<ffffffff8144ce9f>] driver_register+0x5f/0xf0 [ 0.380141] [<ffffffff81d27c91>] ? spi_transport_init+0x79/0x79 [ 0.380141] [<ffffffff8136403b>] register_virtio_driver+0x1b/0x30 [ 0.380141] [<ffffffff81d27d19>] init+0x88/0xd6 [ 0.380141] [<ffffffff81d27c18>] ? scsi_init_procfs+0x5b/0x5b [ 0.380141] [<ffffffff81ce88a7>] do_one_initcall+0x7f/0x10a [ 0.380141] [<ffffffff81ce8aa7>] kernel_init_freeable+0x14a/0x1de [ 0.380141] [<ffffffff81ce8b3b>] ? kernel_init_freeable+0x1de/0x1de [ 0.380141] [<ffffffff817dec20>] ? rest_init+0x80/0x80 [ 0.380141] [<ffffffff817dec29>] kernel_init+0x9/0xf0 [ 0.380141] [<ffffffff817e68fc>] ret_from_fork+0x7c/0xb0 [ 0.380141] [<ffffffff817dec20>] ? rest_init+0x80/0x80 [ 0.380141] RIP [<ffffffff814741ef>] __virtscsi_set_affinity+0x4f/0x120 [ 0.380141] RSP <ffff88003c9f9c08> [ 0.380141] CR2: 0000000000000020 [ 0.380141] ---[ end trace 8074b70c3d5e1d73 ]--- [ 0.475018] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 0.475018] [ 0.475068] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) [ 0.475068] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [jejb: checkpatch fixes] Signed-off-by: Fam Zheng <famz@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-06SCSI: arcmsr: upper 32 of dma address lostDan Carpenter
commit e2c70425f05219b142b3a8a9489a622c736db39d upstream. The original code always set the upper 32 bits to zero because it was doing a shift of the wrong variable. Fixes: 1a4f550a09f8 ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other fixes') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-06SCSI: qla2xxx: fix error handling of qla2x00_mem_alloc()Dan Carpenter
commit b2a72ec32d0f499aaadf41264232517a12326df0 upstream. qla2x00_mem_alloc() returns 1 on success and -ENOMEM on failure. On the one hand the caller assumes non-zero is success but on the other hand the caller also assumes that it returns an error code. I've fixed it to return zero on success and a negative error code on failure. This matches the documentation as well. [jejb: checkpatch fix] Fixes: e315cd28b9ef ('[SCSI] qla2xxx: Code changes for qla data structure refactoring') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23SCSI: storvsc: NULL pointer dereference fixAles Novak
commit b12bb60d6c350b348a4e1460cd68f97ccae9822e upstream. If the initialization of storvsc fails, the storvsc_device_destroy() causes NULL pointer dereference. storvsc_bus_scan() scsi_scan_target() __scsi_scan_target() scsi_probe_and_add_lun(hostdata=NULL) scsi_alloc_sdev(hostdata=NULL) sdev->hostdata = hostdata now the host allocation fails __scsi_remove_device(sdev) calls sdev->host->hostt->slave_destroy() == storvsc_device_destroy(sdev) access of sdev->hostdata->request_mempool Signed-off-by: Ales Novak <alnovak@suse.cz> Signed-off-by: Thomas Abraham <tabraham@suse.com> Reviewed-by: Jiri Kosina <jkosina@suse.cz> Acked-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23SCSI: qla2xxx: Poll during initialization for ISP25xx and ISP83xxGiridhar Malavali
commit b77ed25c9f8402e8b3e49e220edb4ef09ecfbb53 upstream. Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23SCSI: isci: correct erroneous for_each_isci_host macroLukasz Dorau
commit c59053a23d586675c25d789a7494adfdc02fba57 upstream. In the first place, the loop 'for' in the macro 'for_each_isci_host' (drivers/scsi/isci/host.h:314) is incorrect, because it accesses the 3rd element of 2 element array. After the 2nd iteration it executes the instruction: ihost = to_pci_info(pdev)->hosts[2] (while the size of the 'hosts' array equals 2) and reads an out of range element. In the second place, this loop is incorrectly optimized by GCC v4.8 (see http://marc.info/?l=linux-kernel&m=138998871911336&w=2). As a result, on platforms with two SCU controllers, the loop is executed more times than it can be (for i=0,1 and 2). It causes kernel panic during entering the S3 state and the following oops after 'rmmod isci': BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff8131360b>] __list_add+0x1b/0xc0 Oops: 0000 [#1] SMP RIP: 0010:[<ffffffff8131360b>] [<ffffffff8131360b>] __list_add+0x1b/0xc0 Call Trace: [<ffffffff81661b84>] __mutex_lock_slowpath+0x114/0x1b0 [<ffffffff81661c3f>] mutex_lock+0x1f/0x30 [<ffffffffa03e97cb>] sas_disable_events+0x1b/0x50 [libsas] [<ffffffffa03e9818>] sas_unregister_ha+0x18/0x60 [libsas] [<ffffffffa040316e>] isci_unregister+0x1e/0x40 [isci] [<ffffffffa0403efd>] isci_pci_remove+0x5d/0x100 [isci] [<ffffffff813391cb>] pci_device_remove+0x3b/0xb0 [<ffffffff813fbf7f>] __device_release_driver+0x7f/0xf0 [<ffffffff813fc8f8>] driver_detach+0xa8/0xb0 [<ffffffff813fbb8b>] bus_remove_driver+0x9b/0x120 [<ffffffff813fcf2c>] driver_unregister+0x2c/0x50 [<ffffffff813381f3>] pci_unregister_driver+0x23/0x80 [<ffffffffa04152f8>] isci_exit+0x10/0x1e [isci] [<ffffffff810d199b>] SyS_delete_module+0x16b/0x2d0 [<ffffffff81012a21>] ? do_notify_resume+0x61/0xa0 [<ffffffff8166ce29>] system_call_fastpath+0x16/0x1b The loop has been corrected. This patch fixes kernel panic during entering the S3 state and the above oops. Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com> Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com> Tested-by: Lukasz Dorau <lukasz.dorau@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23SCSI: isci: fix reset timeout handlingDan Williams
commit ddfadd7736b677de2d4ca2cd5b4b655368c85a7a upstream. Remove an erroneous BUG_ON() in the case of a hard reset timeout. The reset timeout handler puts the port into the "awaiting link-up" state. The timeout causes the device to be disconnected and we need to be in the awaiting link-up state to re-connect the port. The BUG_ON() made the incorrect assumption that resets never timeout and we always complete the reset in the "resetting" state. Testing this patch also uncovered that libata continues to attempt to reset the port long after the driver has torn down the context. Once the driver has committed to abandoning the link it must indicate to libata that recovery ends by returning -ENODEV from ->lldd_I_T_nexus_reset(). Acked-by: Lukasz Dorau <lukasz.dorau@intel.com> Reported-by: David Milburn <dmilburn@redhat.com> Reported-by: Xun Ni <xun.ni@intel.com> Tested-by: Xun Ni <xun.ni@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-06qla2xxx: Fix kernel panic on selective retransmission requestDr. Greg Wettstein
commit 6f58c780e5a5b43a6d2121e0d43cdcba1d3cc5fc upstream. A selective retransmission request (SRR) is a fibre-channel protocol control request which provides support for requesting retransmission of a data sequence in response to an issue such as frame loss or corruption. These events are experienced infrequently in fibre-channel based networks which makes it difficult to test and assess codepaths which handle these events. We were fortunate enough, for some definition of fortunate, to have a metro-area single-mode SAN link which, at 10 GBPS sustained load levels, would consistently generate SRR's in a SCST based target implementation using our SCST/in-kernel Qlogic target interface driver. In response to an SRR the in-kernel Qlogic target driver immediately panics resulting in a catastrophic storage failure for serviced initiators. The culprit was a debug statement in the qla_target.c file which does not verify that a pointer to the SCSI CDB is not null. The unchecked pointer dereference results in the kernel panic and resultant system failure. The other two references to the SCSI CDB by the SRR handling code use a ternary operator to verify a non-null pointer is being acted on. This patch simply adds a similar test to the implicated debug statement. This patch is a candidate for any stable kernel being maintained since it addresses a potentially catastrophic event with minimal downside. Signed-off-by: Dr. Greg Wettstein <greg@enjellic.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06virtio-scsi: Fix hotcpu_notifier use-after-free with virtscsi_freezeAsias He
commit f466f75385369a181409e46da272db3de6f5c5cb upstream. vqs are freed in virtscsi_freeze but the hotcpu_notifier is not unregistered. We will have a use-after-free usage when the notifier callback is called after virtscsi_freeze. Fixes: 285e71ea6f3583a85e27cb2b9a7d8c35d4c0d558 ("virtio-scsi: reset virtqueue affinity when doing cpu hotplug") Signed-off-by: Asias He <asias.hejun@gmail.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06SCSI: bfa: Chinook quad port 16G FC HBA claim issueVijaya Mohan Guvva
commit dcaf9aed995c2b2a49fb86bbbcfa2f92c797ab5d upstream. Bfa driver crash is observed while pushing the firmware on to chinook quad port card due to uninitialized bfi_image_ct2 access which gets initialized only for CT2 ASIC based cards after request_firmware(). For quard port chinook (CT2 ASIC based), bfi_image_ct2 is not getting initialized as there is no check for chinook PCI device ID before request_firmware and instead bfi_image_cb is initialized as it is the default case for card type check. This patch includes changes to read the right firmware for quad port chinook. Signed-off-by: Vijaya Mohan Guvva <vmohan@brocade.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-15SCSI: sd: Reduce buffer size for vpd requestBernd Schubert
commit af73623f5f10eb3832c87a169b28f7df040a875b upstream. Somehow older areca firmware versions have issues with scsi_get_vpd_page() and a large buffer, the firmware seems to crash and the scsi error-handler will start endless recovery retries. Limiting the buf-size to 64-bytes fixes this issue with older firmware versions (<1.49 for my controller). Fixes a regression with areca controllers and older firmware versions introduced by commit: 66c28f97120e8a621afd5aa7a31c4b85c547d33d Reported-by: Nix <nix@esperi.org.uk> Tested-by: Nix <nix@esperi.org.uk> Signed-off-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-11SCSI: Disable WRITE SAME for RAID and virtual host adapter driversMartin K. Petersen
commit 54b2b50c20a61b51199bedb6e5d2f8ec2568fb43 upstream. Some host adapters do not pass commands through to the target disk directly. Instead they provide an emulated target which may or may not accurately report its capabilities. In some cases the physical device characteristics are reported even when the host adapter is processing commands on the device's behalf. This can lead to adapter firmware hangs or excessive I/O errors. This patch disables WRITE SAME for devices connected to host adapters that provide an emulated target. Driver writers can disable WRITE SAME by setting the no_write_same flag in the host adapter template. [jejb: fix up rejections due to eh_deadline patch] Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-11SCSI: hpsa: return 0 from driver probe function on success, not 1Stephen M. Cameron
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 <scameron@beardog.cce.hp.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-11SCSI: hpsa: do not discard scsi status on aborted commandsStephen M. Cameron
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 <scameron@beardog.cce.hp.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-11SCSI: libsas: fix usage of ata_tf_to_fisDan Williams
commit ae5fbae0ccd982dfca0ce363036ed92f5b13f150 upstream. Since commit 110dd8f19df5 "[SCSI] libsas: fix scr_read/write users and update the libata documentation" we have been passing pmp=1 and is_cmd=0 to ata_tf_to_fis(). Praveen reports that eSATA attached drives do not discover correctly. His investigation found that the BIOS was passing pmp=0 while Linux was passing pmp=1 and failing to discover the drives. Update libsas to follow the libata example of pulling the pmp setting from the ata_link and correct is_cmd to be 1 since all tf's submitted through ->qc_issue are commands. Presumably libsas lldds do not care about is_cmd as they have sideband mechanisms to perform link management. http://marc.info/?l=linux-scsi&m=138179681726990 [jejb: checkpatch fix] Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reported-by: Praveen Murali <pmurali@logicube.com> Tested-by: Praveen Murali <pmurali@logicube.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-11SCSI: bfa: Fix crash when symb name set for offline vportVijaya Mohan Guvva
commit 22a08538dca5c0630226f1c0c58dccd12e463d22 upstream. This patch fixes a crash when tried setting symbolic name for an offline vport through sysfs. Crash is due to uninitialized pointer lport->ns, which gets initialized only on linkup (port online). Signed-off-by: Vijaya Mohan Guvva <vmohan@brocade.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29aacraid: prevent invalid pointer dereferenceMahesh Rajashekhara
commit b4789b8e6be3151a955ade74872822f30e8cd914 upstream. It appears that driver runs into a problem here if fibsize is too small because we allocate user_srbcmd with fibsize size only but later we access it until user_srbcmd->sg.count to copy it over to srbcmd. It is not correct to test (fibsize < sizeof(*user_srbcmd)) because this structure already includes one sg element and this is not needed for commands without data. So, we would recommend to add the following (instead of test for fibsize == 0). Signed-off-by: Mahesh Rajashekhara <Mahesh.Rajashekhara@pmcs.com> Reported-by: Nico Golde <nico@ngolde.de> Reported-by: Fabian Yamaguchi <fabs@goesec.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-13aacraid: missing capable() check in compat ioctlDan Carpenter
commit f856567b930dfcdbc3323261bf77240ccdde01f5 upstream. In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we added a check on CAP_SYS_RAWIO to the ioctl. The compat ioctls need the check as well. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-13SCSI: sd: call blk_pm_runtime_init before add_diskAaron Lu
commit 10c580e4239df5c3344ca00322eca86ab2de880b upstream. Sujit has found a race condition that would make q->nr_pending unbalanced, it occurs as Sujit explained: " sd_probe_async() -> add_disk() -> disk_add_event() -> schedule(disk_events_workfn) sd_revalidate_disk() blk_pm_runtime_init() return; Let's say the disk_events_workfn() calls sd_check_events() which tries to send test_unit_ready() and because of sd_revalidate_disk() trying to send another commands the test_unit_ready() might be re-queued as the tagged command queuing is disabled. So the race condition is - Thread 1 | Thread 2 sd_revalidate_disk() | sd_check_events() ...nr_pending = 0 as q->dev = NULL| scsi_queue_insert() blk_runtime_pm_init() | blk_pm_requeue_request() -> | nr_pending = -1 since | q->dev != NULL " The problem is, the test_unit_ready request doesn't get counted the first time it is queued, so the later decrement of q->nr_pending in blk_pm_requeue_request makes it unbalanced. Fix this by calling blk_pm_runtime_init before add_disk so that all requests initiated there will all be counted. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Reported-and-tested-by: Sujit Reddy Thumma <sthumma@codeaurora.org> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-13esp_scsi: Fix tag state corruption when autosensing.David S. Miller
[ Upstream commit 21af8107f27878813d0364733c0b08813c2c192a ] Meelis Roos reports a crash in esp_free_lun_tag() in the presense of a disk which has died. The issue is that when we issue an autosense command, we do so by hijacking the original command that caused the check-condition. When we do so we clear out the ent->tag[] array when we issue it via find_and_prep_issuable_command(). This is so that the autosense command is forced to be issued non-tagged. That is problematic, because it is the value of ent->tag[] which determines whether we issued the original scsi command as tagged vs. non-tagged (see esp_alloc_lun_tag()). And that, in turn, is what trips up the sanity checks in esp_free_lun_tag(). That function needs the original ->tag[] values in order to free up the tag slot properly. Fix this by remembering the original command's tag values, and having esp_alloc_lun_tag() and esp_free_lun_tag() use them. Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Meelis Roos <mroos@linux.ee> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-26SCSI: sd: Fix potential out-of-bounds accessAlan Stern
commit 984f1733fcee3fbc78d47e26c5096921c5d9946a upstream. This patch fixes an out-of-bounds error in sd_read_cache_type(), found by Google's AddressSanitizer tool. When the loop ends, we know that "offset" lies beyond the end of the data in the buffer, so no Caching mode page was found. In theory it may be present, but the buffer size is limited to 512 bytes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-26SCSI: Allow MPT Fusion SAS 3.0 driver to be built into the kernelGreg Kroah-Hartman
commit 9807b4d94911be4e4efb9a08481b24292a9edf8a upstream. Right now the Makefile for the mpt3sas driver does not even allow the driver to be built into the kernel. So fix that up, as there doesn't seem to be any obvious reason why this shouldn't be done. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2013-09-07SCSI: pm80xx: fix Adaptec 71605H hangHans Verkuil
commit 9504a923924d663e1953f872f0a828e6454a6cfc upstream. The IO command size is 128 bytes for these new controllers as opposed to 64 for the old 8001 controller. The Adaptec out-of-tree driver did this correctly. After comparing the two this turned out to be the crucial difference. So don't hardcode the IO command size, instead use pm8001_ha->iomb_size as that is the correct value for both old and new controllers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Anand Kumar Santhanam <AnandKumar.Santhanam@pmcs.com> Acked-by: Jack Wang <xjtuwjp@gmail.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-29SCSI: lpfc: Don't force CONFIG_GENERIC_CSUM onAnton Blanchard
commit f5944daa0a72316077435c18a6571e73ed338332 upstream. We want ppc64 to be able to select between optimised assembly checksum routines in big endian and the generic lib/checksum.c routines in little endian. The lpfc driver is forcing CONFIG_GENERIC_CSUM on which means we are unable to make the decision to enable it in the arch Kconfig. If the option exists it is always forced on. This got introduced in 3.10 via commit 6a7252fdb0c3 ([SCSI] lpfc: fix up Kconfig dependencies). I spoke to Randy about it and the original issue was with CRC_T10DIF not being defined. As such, remove the select of CONFIG_GENERIC_CSUM. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14SCSI: nsp32: use mdelay instead of large udelay constantsArnd Bergmann
commit b497ceb964a80ebada3b9b3cea4261409039e25a upstream. ARM cannot handle udelay for more than 2 miliseconds, so we should use mdelay instead for those. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: GOTO Masanori <gotom@debian.or.jp> Cc: YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp> Cc: "James E.J. Bottomley" <JBottomley@parallels.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14virtio-scsi: Fix virtqueue affinity setupAsias He
commit aa52aeea2725839bdd3dcce394486e9a043065e0 upstream. vscsi->num_queues counts the number of request virtqueue which does not include the control and event virtqueue. It is wrong to subtract VIRTIO_SCSI_VQ_BASE from vscsi->num_queues. This patch fixes the following panic. (qemu) device_del scsi0 BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [<ffffffff8179b29f>] __virtscsi_set_affinity+0x6f/0x120 PGD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 0 PID: 659 Comm: kworker/0:1 Not tainted 3.11.0-rc2+ #1172 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: kacpi_hotplug _handle_hotplug_event_func task: ffff88007bee1cc0 ti: ffff88007bfe4000 task.ti: ffff88007bfe4000 RIP: 0010:[<ffffffff8179b29f>] [<ffffffff8179b29f>] __virtscsi_set_affinity+0x6f/0x120 RSP: 0018:ffff88007bfe5a38 EFLAGS: 00010202 RAX: 0000000000000010 RBX: ffff880077fd0d28 RCX: 0000000000000050 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000000 RBP: ffff88007bfe5a58 R08: ffff880077f6ff00 R09: 0000000000000001 R10: ffffffff8143e673 R11: 0000000000000001 R12: 0000000000000001 R13: ffff880077fd0800 R14: 0000000000000000 R15: ffff88007bf489b0 FS: 0000000000000000(0000) GS:ffff88007ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000020 CR3: 0000000079f8b000 CR4: 00000000000006f0 Stack: ffff880077fd0d28 0000000000000000 ffff880077fd0800 0000000000000008 ffff88007bfe5a78 ffffffff8179b37d ffff88007bccc800 ffff88007bccc800 ffff88007bfe5a98 ffffffff8179b3b6 ffff88007bccc800 ffff880077fd0d28 Call Trace: [<ffffffff8179b37d>] virtscsi_set_affinity+0x2d/0x40 [<ffffffff8179b3b6>] virtscsi_remove_vqs+0x26/0x50 [<ffffffff8179c7d2>] virtscsi_remove+0x82/0xa0 [<ffffffff814cb6b2>] virtio_dev_remove+0x22/0x70 [<ffffffff8167ca49>] __device_release_driver+0x69/0xd0 [<ffffffff8167cb9d>] device_release_driver+0x2d/0x40 [<ffffffff8167bb96>] bus_remove_device+0x116/0x150 [<ffffffff81679936>] device_del+0x126/0x1e0 [<ffffffff81679a06>] device_unregister+0x16/0x30 [<ffffffff814cb889>] unregister_virtio_device+0x19/0x30 [<ffffffff814cdad6>] virtio_pci_remove+0x36/0x80 [<ffffffff81464ae7>] pci_device_remove+0x37/0x70 [<ffffffff8167ca49>] __device_release_driver+0x69/0xd0 [<ffffffff8167cb9d>] device_release_driver+0x2d/0x40 [<ffffffff8167bb96>] bus_remove_device+0x116/0x150 [<ffffffff81679936>] device_del+0x126/0x1e0 [<ffffffff8145edfc>] pci_stop_bus_device+0x9c/0xb0 [<ffffffff8145f036>] pci_stop_and_remove_bus_device+0x16/0x30 [<ffffffff81474a9e>] acpiphp_disable_slot+0x8e/0x150 [<ffffffff81474f6a>] hotplug_event_func+0xba/0x1a0 [<ffffffff814906c8>] ? acpi_os_release_object+0xe/0x12 [<ffffffff81475911>] _handle_hotplug_event_func+0x31/0x70 [<ffffffff810b5333>] process_one_work+0x183/0x500 [<ffffffff810b66e2>] worker_thread+0x122/0x400 [<ffffffff810b65c0>] ? manage_workers+0x2d0/0x2d0 [<ffffffff810bc5de>] kthread+0xce/0xe0 [<ffffffff810bc510>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff81ca045c>] ret_from_fork+0x7c/0xb0 [<ffffffff810bc510>] ? kthread_freezable_should_stop+0x70/0x70 Code: 01 00 00 00 74 59 45 31 e4 83 bb c8 01 00 00 02 74 46 66 2e 0f 1f 84 00 00 00 00 00 49 63 c4 48 c1 e0 04 48 8b bc 0 3 10 02 00 00 <48> 8b 47 20 48 8b 80 d0 01 00 00 48 8b 40 50 48 85 c0 74 07 be RIP [<ffffffff8179b29f>] __virtscsi_set_affinity+0x6f/0x120 RSP <ffff88007bfe5a38> CR2: 0000000000000020 ---[ end trace 99679331a3775f48 ]--- Signed-off-by: Asias He <asias@redhat.com> Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14SCSI: megaraid_sas: megaraid_sas driver init fails in kdump kernelSumit.Saxena@lsi.com
commit 6431f5d7c6025f8b007af06ea090de308f7e6881 upstream. Problem: When Hardware IOMMU is on, megaraid_sas driver initialization fails in kdump kernel with LSI MegaRAID controller(device id-0x73). Actually this issue needs fix in firmware, but for firmware running in field, this driver fix is proposed to resolve the issue. At firmware initialization time, if firmware does not come to ready state, driver will reset the adapter and retry for firmware transition to ready state unconditionally(not only executed for kdump kernel). Signed-off-by: Sumit Saxena <sumit.saxena@lsi.com> Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14SCSI: Don't attempt to send extended INQUIRY command if skip_vpd_pages is setMartin K. Petersen
commit 7562523e84ddc742fe1f9db8bd76b01acca89f6b upstream. If a device has the skip_vpd_pages flag set we should simply fail the scsi_get_vpd_page() call. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Stuart Foster <smf.linux@ntlworld.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04SCSI: qla2xxx: Properly set the tagging for commands.Saurav Kashyap
commit c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 upstream. This fixes a regression where Xyratex controllers and disks were lost by the driver: https://bugzilla.kernel.org/show_bug.cgi?id=59601 Reported-by: Jack Hill <jackhill@jackhill.us> Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04SCSI: sd: fix crash when UA received on DIF enabled deviceEwan D. Milne
commit 085b513f97d8d799d28491239be4b451bcd8c2c5 upstream. sd_prep_fn will allocate a larger CDB for the command via mempool_alloc for devices using DIF type 2 protection. This CDB was being freed in sd_done, which results in a kernel crash if the command is retried due to a UNIT ATTENTION. This change moves the code to free the larger CDB into sd_unprep_fn instead, which is invoked after the request is complete. It is no longer necessary to call scsi_print_command separately for this case as the ->cmnd will no longer be NULL in the normal code path. Also removed conditional test for DIF type 2 when freeing the larger CDB because the protection_type could have been changed via sysfs while the command was executing. Signed-off-by: Ewan D. Milne <emilne@redhat.com> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04SCSI: isci: Fix a race condition in the SSP task management pathJeff Skirvin
commit 96f15f29038e58e1b0a96483e2b369ff446becf1 upstream. This commit fixes a race condition in the isci driver abort task and SSP device task management path. The race is caused when an I/O termination in the SCU hardware is necessary because of an SSP target timeout condition, and the check of the I/O end state races against the HW-termination-driven end state. The failure of the race meant that no TMF was sent to the device to clean-up the pending I/O. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Reviewed-by: Lukasz Dorau <lukasz.dorau@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-28SCSI: megaraid_sas: fix memory leak if SGL has zero length entriesBjørn Mork
commit 7a6a731bd00ca90d0e250867c3b9c05b5ff0fa49 upstream. commit 98cb7e44 ([SCSI] megaraid_sas: Sanity check user supplied length before passing it to dma_alloc_coherent()) introduced a memory leak. Memory allocated for entries following zero length SGL entries will not be freed. Reference: http://bugs.debian.org/688198 Signed-off-by: Bjørn Mork <bjorn@mork.no> Acked-by: Adam Radford <aradford@gmail.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-28SCSI: mpt3sas: fix for kernel panic when driver loads with HBA conected to ↵Sreekanth Reddy
non LUN 0 configured expander commit b65cfedf4560af65305bd7b3b9f26c02c6fb3660 upstream. With some enclosures when LUN 0 is not created but LUN 1 or LUN X is created then SCSI scan procedure calls target_alloc, slave_alloc call back functions for LUN 0 and slave_destory() for same LUN 0. In these kind of cases within slave_destroy, pointer to scsi_target in _sas_device structure is set to NULL, following which when slave_alloc for LUN 1 is called then starget would not be set properly for this LUN. So, scsi_target pointer pointing to NULL value would lead to a crash later in the discovery procedure. To solve this issue set the sas_device's scsi_target pointer to scsi_device's scsi_target if it is NULL earlier in slave_alloc callback function. Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-28SCSI: mpt3sas: Infinite loops can occur if ↵Sreekanth Reddy
MPI2_IOCSTATUS_CONFIG_INVALID_PAGE is not returned commit 14be49ac965ebd3f8561d57e01ddb22f93f9b454 upstream. Infinite loop can occur if IOCStatus is not equal to MPI2_IOCSTATUS_CONFIG_INVALID_PAGE value in the while loops in functions _scsih_search_responding_sas_devices, _scsih_search_responding_raid_devices and _scsih_search_responding_expanders So, Instead of checking for MPI2_IOCSTATUS_CONFIG_INVALID_PAGE value, in this patch code is modified to check for IOCStatus not equals to MPI2_IOCSTATUS_SUCCESS to break the while loop. Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25SCSI: mpt2sas: Fix for issue Missing delay not getting set during system bootupReddy, Sreekanth
commit b0df96a0068daee4f9c2189c29b9053eb6e46b17 upstream. Missing delay is not getting set properly. The reason is that it is not defined in the same file from where it is being invoked. The fix is to move the missing delay module parameter from mpt2sas_base.c to mpt2sas_scsh.c. Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25SCSI: mpt2sas: fix firmware failure with wrong task attributeSreekanth Reddy
commit 48ba2efc382f94fae16ca8ca011e5961a81ad1ea upstream. When SCSI command is received with task attribute not set, set it to SIMPLE. Previously it is set to untagged. This causes the firmware to fail the commands. Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25SCSI: aacraid: Fix for arrays are going offline in the system. System hangsMahesh Rajashekhara
commit c5bebd829dd95602c15f8da8cc50fa938b5e0254 upstream. One of the customer had reported that the set of raid logical arrays will become unavailable (I/O offline) after a long hours of IO stress test. The OS wouldn`t be accessible afterwards and require a hard reset. This driver patch has a fix for race condition between the doorbell and the circular buffer. The driver is modified to do an extra read after clearing the doorbell in case there had been a completion posted during the small timing window. With this fix, we ran IO stress for ~13 days. There were no IO failures. Signed-off-by: Mahesh Rajashekhara <Mahesh.Rajashekhara@pmcs.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25SCSI: sd: Update WRITE SAME heuristicsMartin K. Petersen
commit 66c28f97120e8a621afd5aa7a31c4b85c547d33d upstream. SATA drives located behind a SAS controller would incorrectly receive WRITE SAME commands. Tweak the heuristics so that: - If REPORT SUPPORTED OPERATION CODES is provided we will use that to choose between WRITE SAME(16), WRITE SAME(10) and disabled. This also fixes an issue with the old code which would issue WRITE SAME(10) despite the command not being whitelisted in REPORT SUPPORTED OPERATION CODES. - If REPORT SUPPORTED OPERATION CODES is not provided we will fall back to WRITE SAME(10) unless the device has an ATA Information VPD page. The assumption is that a SATL which is smart enough to implement WRITE SAME would also provide REPORT SUPPORTED OPERATION CODES. To facilitate the new heuristics scsi_report_opcode() has been modified to so we can distinguish between "operation not supported" and "RSOC not supported". Reported-by: H. Peter Anvin <hpa@zytor.com> Tested-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-07-16 19:09:02 +0000