linux-stable.git/drivers/scsi, branch v3.12.20

mpt2sas: Don't disable device twice at suspend.

2014-05-15T07:55:52+00:00

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 
Signed-off-by: James Bottomley 
Signed-off-by: Jiri Slaby

virtio-scsi: Skip setting affinity on uninitialized vq

2014-05-15T07:55:51+00:00

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: [] __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:[]  [] __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]  [] virtscsi_set_affinity+0x28/0x40
[    0.380141]  [] virtscsi_remove_vqs+0x21/0x50
[    0.380141]  [] virtscsi_init+0x91/0x240
[    0.380141]  [] ? vp_get+0x50/0x70
[    0.380141]  [] virtscsi_probe+0xf4/0x280
[    0.380141]  [] virtio_dev_probe+0xe5/0x140
[    0.380141]  [] driver_probe_device+0x89/0x230
[    0.380141]  [] __driver_attach+0x9b/0xa0
[    0.380141]  [] ? driver_probe_device+0x230/0x230
[    0.380141]  [] ? driver_probe_device+0x230/0x230
[    0.380141]  [] bus_for_each_dev+0x8c/0xb0
[    0.380141]  [] driver_attach+0x19/0x20
[    0.380141]  [] bus_add_driver+0x198/0x220
[    0.380141]  [] driver_register+0x5f/0xf0
[    0.380141]  [] ? spi_transport_init+0x79/0x79
[    0.380141]  [] register_virtio_driver+0x1b/0x30
[    0.380141]  [] init+0x88/0xd6
[    0.380141]  [] ? scsi_init_procfs+0x5b/0x5b
[    0.380141]  [] do_one_initcall+0x7f/0x10a
[    0.380141]  [] kernel_init_freeable+0x14a/0x1de
[    0.380141]  [] ? kernel_init_freeable+0x1de/0x1de
[    0.380141]  [] ? rest_init+0x80/0x80
[    0.380141]  [] kernel_init+0x9/0xf0
[    0.380141]  [] ret_from_fork+0x7c/0xb0
[    0.380141]  [] ? rest_init+0x80/0x80
[    0.380141] RIP  [] __virtscsi_set_affinity+0x4f/0x120
[    0.380141]  RSP 
[    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 
Acked-by: Paolo Bonzini 
Signed-off-by: James Bottomley 
Signed-off-by: Jiri Slaby

SCSI: arcmsr: upper 32 of dma address lost

2014-05-15T07:55:15+00:00

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 
Signed-off-by: James Bottomley 
Signed-off-by: Jiri Slaby

SCSI: qla2xxx: fix error handling of qla2x00_mem_alloc()

2014-05-15T07:55:14+00:00

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 
Acked-by: Saurav Kashyap 
Signed-off-by: James Bottomley 
Signed-off-by: Jiri Slaby

SCSI: storvsc: NULL pointer dereference fix

2014-03-24T08:45:04+00:00

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 
Signed-off-by: Thomas Abraham 
Reviewed-by: Jiri Kosina 
Acked-by: K. Y. Srinivasan 
Signed-off-by: James Bottomley 
Signed-off-by: Jiri Slaby

SCSI: qla2xxx: Fix multiqueue MSI-X registration.

2014-03-24T08:45:04+00:00

commit f324777ea88bab2522602671e46fc0851d7d5e35 upstream.

This fixes requesting of the MSI-X vectors for the base response queue.
The iteration in the for loop in qla24xx_enable_msix() was incorrect.
We should only iterate of the first two MSI-X vectors and not the total
number of MSI-X vectors that have given to the driver for this device
from pci_enable_msix() in this function.

Signed-off-by: Chad Dupuis 
Signed-off-by: Saurav Kashyap 
Signed-off-by: James Bottomley 
Signed-off-by: Jiri Slaby

SCSI: qla2xxx: Poll during initialization for ISP25xx and ISP83xx

2014-03-24T08:45:04+00:00

commit b77ed25c9f8402e8b3e49e220edb4ef09ecfbb53 upstream.

Signed-off-by: Giridhar Malavali 
Signed-off-by: Saurav Kashyap 
Signed-off-by: James Bottomley 
Signed-off-by: Jiri Slaby

SCSI: isci: correct erroneous for_each_isci_host macro

2014-03-24T08:45:03+00:00

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: [] __list_add+0x1b/0xc0
Oops: 0000 [#1] SMP
RIP: 0010:[]  [] __list_add+0x1b/0xc0
Call Trace:
  [] __mutex_lock_slowpath+0x114/0x1b0
  [] mutex_lock+0x1f/0x30
  [] sas_disable_events+0x1b/0x50 [libsas]
  [] sas_unregister_ha+0x18/0x60 [libsas]
  [] isci_unregister+0x1e/0x40 [isci]
  [] isci_pci_remove+0x5d/0x100 [isci]
  [] pci_device_remove+0x3b/0xb0
  [] __device_release_driver+0x7f/0xf0
  [] driver_detach+0xa8/0xb0
  [] bus_remove_driver+0x9b/0x120
  [] driver_unregister+0x2c/0x50
  [] pci_unregister_driver+0x23/0x80
  [] isci_exit+0x10/0x1e [isci]
  [] SyS_delete_module+0x16b/0x2d0
  [] ? do_notify_resume+0x61/0xa0
  [] 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 
Reviewed-by: Maciej Patelczyk 
Tested-by: Lukasz Dorau 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
Signed-off-by: Jiri Slaby

SCSI: isci: fix reset timeout handling

2014-03-24T08:45:03+00:00

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 
Reported-by: David Milburn 
Reported-by: Xun Ni 
Tested-by: Xun Ni 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
Signed-off-by: Jiri Slaby

qla2xxx: Fix kernel panic on selective retransmission request

2014-03-05T16:13:54+00:00

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 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Jiri Slaby