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

aacraid: prevent invalid pointer dereference

2014-01-03T04:33:35+00:00

commit b4789b8e6be3151a955ade74872822f30e8cd914 upstream.

It appears that driver runs into a problem here if fibsize is too small
because we allocate user_srbcmd with fibsize size only but later we
access it until user_srbcmd->sg.count to copy it over to srbcmd.

It is not correct to test (fibsize < sizeof(*user_srbcmd)) because this
structure already includes one sg element and this is not needed for
commands without data.  So, we would recommend to add the following
(instead of test for fibsize == 0).

Signed-off-by: Mahesh Rajashekhara 
Reported-by: Nico Golde 
Reported-by: Fabian Yamaguchi 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

hpsa: return 0 from driver probe function on success, not 1

2014-01-03T04:33:27+00:00

commit 88bf6d62db4393fa03a58bada9d746312d5b496f upstream.

A return value of 1 is interpreted as an error.  See pci_driver.
in local_pci_probe().  If you're wondering how this ever could
have worked, it's because it used to be the case that only return
values less than zero were interpreted as failure.  But even in
the current kernel if the driver registers its various entry
points with the kernel, and then returns a value which is
interpreted as failure, those registrations aren't undone, so
the driver still mostly works.  However, the driver's remove
function wouldn't be called on rmmod, and pci power management
functions wouldn't work.  In the case of Smart Array, since it
has a battery backed cache (or else no cache) even if the driver
is not shut down properly as long as there is no outstanding
i/o, nothing too bad happens, which is why it took so long to
notice.

Requesting backport to stable because the change to pci-driver.c
which requires driver probe functions to return 0 occurred between
2.6.35 and 2.6.36 (the pci power management breakage) and again
between 3.7 and 3.8 (pci_dev->driver getting set to NULL in
local_pci_probe() preventing driver remove function from being
called on rmmod.)

Signed-off-by: Stephen M. Cameron 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

hpsa: do not discard scsi status on aborted commands

2014-01-03T04:33:27+00:00

commit 2e311fbabdc23b7eaec77313dc3b9a151a5407b5 upstream.

We inadvertantly discarded the scsi status for aborted commands.
For some commands (e.g. reads from tape drives) these can't be retried,
and if we discarded the scsi status, the scsi mid layer couldn't notice
anything was wrong and the error was not reported.

Signed-off-by: Stephen M. Cameron 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

libsas: fix usage of ata_tf_to_fis

2014-01-03T04:33:26+00:00

commit ae5fbae0ccd982dfca0ce363036ed92f5b13f150 upstream.

Since commit 110dd8f19df5 "[SCSI] libsas: fix scr_read/write users and
update the libata documentation" we have been passing pmp=1 and is_cmd=0
to ata_tf_to_fis().  Praveen reports that eSATA attached drives do not
discover correctly.  His investigation found that the BIOS was passing
pmp=0 while Linux was passing pmp=1 and failing to discover the drives.
Update libsas to follow the libata example of pulling the pmp setting
from the ata_link and correct is_cmd to be 1 since all tf's submitted
through ->qc_issue are commands.  Presumably libsas lldds do not care
about is_cmd as they have sideband mechanisms to perform link
management.

http://marc.info/?l=linux-scsi&m=138179681726990

[jejb: checkpatch fix]
Signed-off-by: Dan Williams 
Reported-by: Praveen Murali 
Tested-by: Praveen Murali 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

aacraid: missing capable() check in compat ioctl

2013-11-28T14:02:06+00:00

commit f856567b930dfcdbc3323261bf77240ccdde01f5 upstream.

In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we
added a check on CAP_SYS_RAWIO to the ioctl.  The compat ioctls need the
check as well.

Signed-off-by: Dan Carpenter 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

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