linux-toradex.git/drivers/scsi, branch v3.10.42

SCSI: megaraid: missing bounds check in mimd_to_kioc()

2014-05-31T04:52:11+00:00

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 
Reported-by: Fabian Yamaguchi 
Signed-off-by: Dan Carpenter 
Acked-by: Sumit Saxena 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: dual scan thread bug fix

2014-05-31T04:52:11+00:00

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 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

scsi: fix our current target reap infrastructure

2014-05-31T04:52:11+00:00

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 
Tested-by: Sarah Sharp 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

mpt2sas: Don't disable device twice at suspend.

2014-05-13T11:59:41+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: Greg Kroah-Hartman

virtio-scsi: Skip setting affinity on uninitialized vq

2014-05-13T11:59:41+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: Greg Kroah-Hartman

SCSI: arcmsr: upper 32 of dma address lost

2014-05-06T14:55:30+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: Greg Kroah-Hartman

SCSI: qla2xxx: fix error handling of qla2x00_mem_alloc()

2014-05-06T14:55:30+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: Greg Kroah-Hartman

SCSI: storvsc: NULL pointer dereference fix

2014-03-24T04:38:19+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: Greg Kroah-Hartman

SCSI: qla2xxx: Poll during initialization for ISP25xx and ISP83xx

2014-03-24T04:38:19+00:00

commit b77ed25c9f8402e8b3e49e220edb4ef09ecfbb53 upstream.

Signed-off-by: Giridhar Malavali 
Signed-off-by: Saurav Kashyap 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: isci: correct erroneous for_each_isci_host macro

2014-03-24T04:38:19+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: Greg Kroah-Hartman