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

SCSI: arcmsr: upper 32 of dma address lost

2014-05-06T14:51:43+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: storvsc: NULL pointer dereference fix

2014-03-24T04:37:08+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:37:07+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:37:07+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

SCSI: isci: fix reset timeout handling

2014-03-24T04:37:07+00:00

commit ddfadd7736b677de2d4ca2cd5b4b655368c85a7a upstream.

Remove an erroneous BUG_ON() in the case of a hard reset timeout.  The
reset timeout handler puts the port into the "awaiting link-up" state.
The timeout causes the device to be disconnected and we need to be in
the awaiting link-up state to re-connect the port.  The BUG_ON() made
the incorrect assumption that resets never timeout and we always
complete the reset in the "resetting" state.

Testing this patch also uncovered that libata continues to attempt to
reset the port long after the driver has torn down the context.  Once
the driver has committed to abandoning the link it must indicate to
libata that recovery ends by returning -ENODEV from
->lldd_I_T_nexus_reset().

Acked-by: Lukasz Dorau 
Reported-by: David Milburn 
Reported-by: Xun Ni 
Tested-by: Xun Ni 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: bfa: Chinook quad port 16G FC HBA claim issue

2014-02-06T19:05:48+00:00

commit dcaf9aed995c2b2a49fb86bbbcfa2f92c797ab5d upstream.

Bfa driver crash is observed while pushing the firmware on to chinook
quad port card due to uninitialized bfi_image_ct2 access which gets
initialized only for CT2 ASIC based cards after request_firmware().
For quard port chinook (CT2 ASIC based), bfi_image_ct2 is not getting
initialized as there is no check for chinook PCI device ID before
request_firmware and instead bfi_image_cb is initialized as it is the
default case for card type check.

This patch includes changes to read the right firmware for quad port chinook.

Signed-off-by: Vijaya Mohan Guvva 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

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

2013-12-12T06:34:10+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: Greg Kroah-Hartman

SCSI: hpsa: do not discard scsi status on aborted commands

2013-12-12T06:34:10+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: Greg Kroah-Hartman

SCSI: libsas: fix usage of ata_tf_to_fis

2013-12-12T06:34:10+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: Greg Kroah-Hartman

aacraid: prevent invalid pointer dereference

2013-11-29T18:50:30+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 
Cc: Kees Cook 
Signed-off-by: Greg Kroah-Hartman