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

iscsi: don't hang in endless loop if no targets present

2013-10-26T20:06:12+00:00

commit 46a7c17d26967922092f3a8291815ffb20f6cabe upstream.

iscsi_if_send_reply() may return -ESRCH if there were no targets to send
data to. Currently we're ignoring this value and looping in attempt to do it
over and over, which will usually lead in a hung task like this one:

[ 4920.817298] INFO: task trinity:9074 blocked for more than 120 seconds.
[ 4920.818527] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4920.819982] trinity         D 0000000000000000  5504  9074   2756 0x00000004
[ 4920.825374]  ffff880003961a98 0000000000000086 ffff8800001aa000 ffff8800001aa000
[ 4920.826791]  00000000001d4340 ffff880003961fd8 ffff880003960000 00000000001d4340
[ 4920.828241]  00000000001d4340 00000000001d4340 ffff880003961fd8 00000000001d4340
[ 4920.833231]
[ 4920.833519] Call Trace:
[ 4920.834010]  [] schedule+0x3a/0x50
[ 4920.834953]  [] __mutex_lock_common+0x209/0x5b0
[ 4920.836226]  [] ? iscsi_if_rx+0x2d/0x990
[ 4920.837281]  [] ? sched_clock+0x13/0x20
[ 4920.838305]  [] ? iscsi_if_rx+0x2d/0x990
[ 4920.839336]  [] mutex_lock_nested+0x40/0x50
[ 4920.840423]  [] iscsi_if_rx+0x2d/0x990
[ 4920.841434]  [] ? sub_preempt_count+0x9d/0xd0
[ 4920.842548]  [] ? _raw_read_unlock+0x30/0x60
[ 4920.843666]  [] netlink_unicast+0x1ae/0x1f0
[ 4920.844751]  [] netlink_sendmsg+0x227/0x350
[ 4920.845850]  [] ? sock_update_netprioidx+0xdd/0x1b0
[ 4920.847060]  [] ? sock_update_netprioidx+0x52/0x1b0
[ 4920.848276]  [] sock_aio_write+0x166/0x180
[ 4920.849348]  [] ? get_parent_ip+0x11/0x50
[ 4920.850428]  [] do_sync_write+0xda/0x120
[ 4920.851465]  [] ? sub_preempt_count+0x9d/0xd0
[ 4920.852579]  [] ? get_parent_ip+0x11/0x50
[ 4920.853608]  [] ? security_file_permission+0x27/0xb0
[ 4920.854821]  [] vfs_write+0x16c/0x180
[ 4920.855781]  [] sys_write+0x4f/0xa0
[ 4920.856798]  [] system_call_fastpath+0x16/0x1b
[ 4920.877487] 1 lock held by trinity/9074:
[ 4920.878239]  #0:  (rx_queue_mutex){+.+...}, at: [] iscsi_if_rx+0x2d/0x990
[ 4920.880005] Kernel panic - not syncing: hung_task: blocked tasks

Signed-off-by: Sasha Levin 
Acked-by: Mike Christie 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

esp_scsi: Fix tag state corruption when autosensing.

2013-10-26T20:06:09+00:00

[ 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 
Tested-by: Meelis Roos 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

sd: Fix potential out-of-bounds access

2013-10-26T20:06:03+00:00

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 
Reported-by: Dmitry Vyukov 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

SCSI: nsp32: use mdelay instead of large udelay constants

2013-09-10T00:57:29+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 
Signed-off-by: Ben Hutchings

megaraid_sas: megaraid_sas driver init fails in kdump kernel

2013-09-10T00:57:19+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: Ben Hutchings

sd: fix crash when UA received on DIF enabled device

2013-08-02T20:15:05+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: Ben Hutchings

qla2xxx: Properly set the tagging for commands.

2013-08-02T20:15:04+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: Ben Hutchings

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

2013-08-02T20:15:04+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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

Fix incorrect memset in bnx2fc_parse_fcp_rsp

2013-08-02T20:14:52+00:00

commit 16da05b1158d1bcb31656e636a8736a663b1cf1f upstream.

gcc 4.8 warns because the memset only clears sizeof(char *) bytes, not
the whole buffer. Use the correct buffer size and clear the whole sense
buffer.

/backup/lsrc/git/linux-lto-2.6/drivers/scsi/bnx2fc/bnx2fc_io.c: In
function 'bnx2fc_parse_fcp_rsp':
/backup/lsrc/git/linux-lto-2.6/drivers/scsi/bnx2fc/bnx2fc_io.c:1810:41:
warning: argument to 'sizeof' in 'memset' call is the same expression as
the destination; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]
   memset(sc_cmd->sense_buffer, 0, sizeof(sc_cmd->sense_buffer));
                                         ^

Signed-off-by: Andi Kleen 
Acked-by: Bhanu Prakash Gollapudi 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

megaraid_sas: fix memory leak if SGL has zero length entries

2013-07-27T04:34:30+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: Ben Hutchings