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

hpsa: add small delay when using PCI Power Management to reset for kump

2011-11-11T17:44:34+00:00

commit c4853efec665134b2e6fc9c13447323240980351 upstream.

The P600 requires a small delay when changing states. Otherwise we may think
the board did not reset and we bail. This for kdump only and is particular
to the P600.

Signed-off-by: Mike Miller 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

mpt2sas: Fix for system hang when discovery in progress

2011-11-11T17:44:24+00:00

commit 0167ac67ff6f35bf2364f7672c8012b0cd40277f upstream.

Fix for issue : While discovery is in progress, hot unplug and hot plug of
enclosure connected to the controller card is causing system to hang.

When a device is in the process of being detected at driver load time then
if it is removed, the device that is no longer present will not be added
to the list. So the code in _scsih_probe_sas() is rearranged as such so
the devices that failed to be detected are not added to the list.

Signed-off-by: Nagalakshmi Nandigama 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

Fix block queue and elevator memory leak in scsi_alloc_sdev

2011-11-11T17:44:23+00:00

commit f7c9c6bb14f3104608a3a83cadea10a6943d2804 upstream.

When looking at memory consumption issues I noticed quite a
lot of memory in the kmalloc-2048 bucket:

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
  6561   6471  98%    2.30K    243       27     15552K kmalloc-2048

Over 15MB. slub debug shows that cfq is responsible for almost
all of it:

# sort -nr /sys/kernel/slab/kmalloc-2048/alloc_calls
6402 .cfq_init_queue+0xec/0x460 age=43423/43564/43655 pid=1 cpus=4,11,13

In scsi_alloc_sdev we do scsi_alloc_queue but if slave_alloc
fails we don't free it with scsi_free_queue.

The patch below fixes the issue:

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
   135     72  53%    2.30K      5       27       320K kmalloc-2048

# cat /sys/kernel/slab/kmalloc-2048/alloc_calls
3 .cfq_init_queue+0xec/0x460 age=3811/3876/3925 pid=1 cpus=4,11,13

Signed-off-by: Anton Blanchard 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

Make scsi_free_queue() kill pending SCSI commands

2011-11-11T17:44:22+00:00

commit 3308511c93e6ad0d3c58984ecd6e5e57f96b12c8 upstream.

Make sure that SCSI device removal via scsi_remove_host() does finish
all pending SCSI commands. Currently that's not the case and hence
removal of a SCSI host during I/O can cause a deadlock. See also
"blkdev_issue_discard() hangs forever if underlying storage device is
removed" (http://bugzilla.kernel.org/show_bug.cgi?id=40472). See also
http://lkml.org/lkml/2011/8/27/6.

Signed-off-by: Bart Van Assche 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

scsi_dh: check queuedata pointer before proceeding further

2011-11-11T17:44:21+00:00

commit a18a920c70d48a8e4a2b750d8a183b3c1a4be514 upstream.

This patch validates sdev pointer in scsi_dh_activate before proceeding further.

Without this check we might see the panic as below. I have seen this
panic multiple times..

Call trace:

 #0 [ffff88007d647b50] machine_kexec at ffffffff81020902
 #1 [ffff88007d647ba0] crash_kexec at ffffffff810875b0
 #2 [ffff88007d647c70] oops_end at ffffffff8139c650
 #3 [ffff88007d647c90] __bad_area_nosemaphore at ffffffff8102dd15
 #4 [ffff88007d647d50] page_fault at ffffffff8139b8cf
    [exception RIP: scsi_dh_activate+0x82]
    RIP: ffffffffa0041922  RSP: ffff88007d647e00  RFLAGS: 00010046
    RAX: 0000000000000000  RBX: 0000000000000000  RCX: 00000000000093c5
    RDX: 00000000000093c5  RSI: ffffffffa02e6640  RDI: ffff88007cc88988
    RBP: 000000000000000f   R8: ffff88007d646000   R9: 0000000000000000
    R10: ffff880082293790  R11: 00000000ffffffff  R12: ffff88007cc88988
    R13: 0000000000000000  R14: 0000000000000286  R15: ffff880037b845e0
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0000
 #5 [ffff88007d647e38] run_workqueue at ffffffff81060268
 #6 [ffff88007d647e78] worker_thread at ffffffff81060386
 #7 [ffff88007d647ee8] kthread at ffffffff81064436
 #8 [ffff88007d647f48] kernel_thread at ffffffff81003fba

Signed-off-by: Babu Moger 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

st: fix race in st_scsi_execute_end

2011-11-11T17:44:20+00:00

commit c68bf8eeaa57c852e74adcf597237be149eef830 upstream.

The call to complete() in st_scsi_execute_end() wakes up sleeping thread
in write_behind_check(), which frees the st_request, thus invalidating
the pointer to the associated bio structure, which is then passed to the
blk_rq_unmap_user(). Fix by storing pointer to bio structure into
temporary local variable.

This bug is present since at least linux-2.6.32.

Signed-off-by: Petr Uzel 
Reported-by: Juergen Groß 
Reviewed-by: Jan Kara 
Acked-by: Kai Mäkisara 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

isci: fix missed unlock in apc_agent_timeout()

2011-11-11T17:42:31+00:00

commit 983d3fdd332742167d0482c06fd29cf4b8a687c0 upstream.

Needed to jump to scic_lock unlock.

Also spotted by coccicheck.

Signed-off-by: Jeff Skirvin 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

isci: fix support for large smp requests

2011-11-11T17:42:30+00:00

commit 54b5e3a4bfa3452bc10cd4da672099ccc46b8c09 upstream.

Kill the local smp response buffer.

Besides being unnecessary, it is too small (currently truncates
responses to 60 bytes).  The mid-layer will have already allocated a
sufficiently sized buffer, just kmap and copy into it directly.

Reported-by: Derick Marks 
Tested-by: Derick Marks 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

libsas: set sas_address and device type of rphy

2011-11-11T17:42:30+00:00

commit bb041a0e9c31229071b6e56e1d0d8374af0d2038 upstream.

Libsas forget to set the sas_address and device type of rphy lead to file
under /sys/class/sas_x show wrong value, fix that.

Signed-off-by: Jack Wang 
Tested-by: Crystal Yu 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

ipr: Always initiate hard reset in kdump kernel

2011-11-11T17:42:30+00:00

commit 5d7c20b7fa5c6ca19e871b4050e321c99d32bd43 upstream.

During kdump testing I noticed timeouts when initialising each IPR
adapter. While the driver has logic to detect an adapter in an
indeterminate state, it wasn't triggering and each adapter went
through a 5 minute timeout before finally going operational.

Some analysis showed the needs_hard_reset flag wasn't getting set.
We can check the reset_devices kernel parameter which is set by
kdump and force a full reset. This fixes the problem.

Signed-off-by: Anton Blanchard 
Acked-by: Brian King 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman