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

SCSI: nsp32: use mdelay instead of large udelay constants

2013-08-15T05:59:10+00:00

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 
Acked-by: GOTO Masanori 
Cc: YOKOTA Hiroshi 
Cc: "James E.J. Bottomley" 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

virtio-scsi: Fix virtqueue affinity setup

2013-08-15T05:59:04+00:00

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: [] __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:[]  [] __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:
  [] virtscsi_set_affinity+0x2d/0x40
  [] virtscsi_remove_vqs+0x26/0x50
  [] virtscsi_remove+0x82/0xa0
  [] virtio_dev_remove+0x22/0x70
  [] __device_release_driver+0x69/0xd0
  [] device_release_driver+0x2d/0x40
  [] bus_remove_device+0x116/0x150
  [] device_del+0x126/0x1e0
  [] device_unregister+0x16/0x30
  [] unregister_virtio_device+0x19/0x30
  [] virtio_pci_remove+0x36/0x80
  [] pci_device_remove+0x37/0x70
  [] __device_release_driver+0x69/0xd0
  [] device_release_driver+0x2d/0x40
  [] bus_remove_device+0x116/0x150
  [] device_del+0x126/0x1e0
  [] pci_stop_bus_device+0x9c/0xb0
  [] pci_stop_and_remove_bus_device+0x16/0x30
  [] acpiphp_disable_slot+0x8e/0x150
  [] hotplug_event_func+0xba/0x1a0
  [] ? acpi_os_release_object+0xe/0x12
  [] _handle_hotplug_event_func+0x31/0x70
  [] process_one_work+0x183/0x500
  [] worker_thread+0x122/0x400
  [] ? manage_workers+0x2d0/0x2d0
  [] kthread+0xce/0xe0
  [] ? kthread_freezable_should_stop+0x70/0x70
  [] ret_from_fork+0x7c/0xb0
  [] ? 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  [] __virtscsi_set_affinity+0x6f/0x120
  RSP 
 CR2: 0000000000000020
 ---[ end trace 99679331a3775f48 ]---

Signed-off-by: Asias He 
Reviewed-by: Wanlong Gao 
Signed-off-by: Rusty Russell 
Signed-off-by: Greg Kroah-Hartman

SCSI: megaraid_sas: megaraid_sas driver init fails in kdump kernel

2013-08-15T05:59:04+00:00

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

SCSI: Don't attempt to send extended INQUIRY command if skip_vpd_pages is set

2013-08-15T05:59:04+00:00

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 
Acked-by: Alan Stern 
Tested-by: Stuart Foster 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: qla2xxx: Properly set the tagging for commands.

2013-08-04T08:50:41+00:00

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

SCSI: sd: fix crash when UA received on DIF enabled device

2013-08-04T08:50:41+00:00

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 
Acked-by: Martin K. Petersen 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: isci: Fix a race condition in the SSP task management path

2013-08-04T08:50:40+00:00

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

SCSI: megaraid_sas: fix memory leak if SGL has zero length entries

2013-07-28T23:30:12+00:00

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

SCSI: mpt3sas: fix for kernel panic when driver loads with HBA conected to non LUN 0 configured expander

2013-07-28T23:30:12+00:00

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

SCSI: mpt3sas: Infinite loops can occur if MPI2_IOCSTATUS_CONFIG_INVALID_PAGE is not returned

2013-07-28T23:30:12+00:00

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