linux-stable.git/drivers/scsi, branch v4.1.26

aacraid: Fix for KDUMP driver hang

2016-06-03T23:15:38+00:00

[ Upstream commit 78cbccd3bd683c295a44af8050797dc4a41376ff ]

When KDUMP is triggered the driver first talks to the firmware in INTX
mode, but the adapter firmware is still in MSIX mode. Therefore the first
driver command hangs since the driver is waiting for an INTX response and
firmware gives a MSIX response. If when the OS is installed on a RAID
drive created by the adapter KDUMP will hang since the driver does not
receive a response in sync mode.

Fixed by: Change the firmware to INTX mode if it is in MSIX mode before
sending the first sync command.

Cc: stable@vger.kernel.org
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

aacraid: Fix for aac_command_thread hang

2016-06-03T23:15:38+00:00

[ Upstream commit fc4bf75ea300a5e62a2419f89dd0e22189dd7ab7 ]

Typically under error conditions, it is possible for aac_command_thread()
to miss the wakeup from kthread_stop() and go back to sleep, causing it
to hang aac_shutdown.

In the observed scenario, the adapter is not functioning correctly and so
aac_fib_send() never completes (or time-outs depending on how it was
called). Shortly after aac_command_thread() starts it performs
aac_fib_send(SendHostTime) which hangs. When aac_probe_one
/aac_get_adapter_info send time outs, kthread_stop is called which breaks
the command thread out of it's hang.

The code will still go back to sleep in schedule_timeout() without
checking kthread_should_stop() so it causes aac_probe_one to hang until
the schedule_timeout() which is 30 minutes.

Fixed by: Adding another kthread_should_stop() before schedule_timeout()
Cc: stable@vger.kernel.org
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 

Signed-off-by: Sasha Levin

aacraid: Relinquish CPU during timeout wait

2016-06-03T23:15:37+00:00

[ Upstream commit 07beca2be24cc710461c0b131832524c9ee08910 ]

aac_fib_send has a special function case for initial commands during
driver initialization using wait < 0(pseudo sync mode). In this case,
the command does not sleep but rather spins checking for timeout.This
loop is calls cpu_relax() in an attempt to allow other processes/threads
to use the CPU, but this function does not relinquish the CPU and so the
command will hog the processor. This was observed in a KDUMP
"crashkernel" and that prevented the "command thread" (which is
responsible for completing the command from being timed out) from
starting because it could not get the CPU.

Fixed by replacing "cpu_relax()" call with "schedule()"
Cc: stable@vger.kernel.org
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 

Signed-off-by: Sasha Levin

sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes

2016-04-20T05:03:43+00:00

[ Upstream commit f08bb1e0dbdd0297258d0b8cd4dbfcc057e57b2a ]

During revalidate we check whether device capacity has changed before we
decide whether to output disk information or not.

The check for old capacity failed to take into account that we scaled
sdkp->capacity based on the reported logical block size. And therefore
the capacity test would always fail for devices with sectors bigger than
512 bytes and we would print several copies of the same discovery
information.

Avoid scaling sdkp->capacity and instead adjust the value on the fly
when setting the block device capacity and generating fake C/H/S
geometry.

Signed-off-by: Martin K. Petersen 
Cc: 
Reported-by: Hannes Reinecke 
Reviewed-by: Hannes Reinicke 
Reviewed-by: Ewan Milne 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

sg: fix dxferp in from_to case

2016-04-18T12:50:52+00:00

[ Upstream commit 5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 ]

One of the strange things that the original sg driver did was let the
user provide both a data-out buffer (it followed the sg_header+cdb)
_and_ specify a reply length greater than zero. What happened was that
the user data-out buffer was copied into some kernel buffers and then
the mid level was told a read type operation would take place with the
data from the device overwriting the same kernel buffers. The user would
then read those kernel buffers back into the user space.

From what I can tell, the above action was broken by commit fad7f01e61bf
("sg: set dxferp to NULL for READ with the older SG interface") in 2008
and syzkaller found that out recently.

Make sure that a user space pointer is passed through when data follows
the sg_header structure and command.  Fix the abnormal case when a
non-zero reply_len is also given.

Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6
Cc:  #v2.6.28+
Signed-off-by: Douglas Gilbert 
Reviewed-by: Ewan Milne 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

be2iscsi: set the boot_kset pointer to NULL in case of failure

2016-04-18T12:50:50+00:00

[ Upstream commit 84bd64993f916bcf86270c67686ecf4cea7b8933 ]

In beiscsi_setup_boot_info(), the boot_kset pointer should be set to
NULL in case of failure otherwise an invalid pointer dereference may
occur later.

Cc: 
Signed-off-by: Maurizio Lombardi 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Jitendra Bhivare 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

aic7xxx: Fix queue depth handling

2016-04-18T12:50:39+00:00

[ Upstream commit 5a51a7abca133860a6f4429655a9eda3c4afde32 ]

We were setting the queue depth correctly, then setting it back to
two. If you hit this as a bisection point then please send me an email
as it would imply we've been hiding other bugs with this one.

Cc: 
Signed-off-by: Alan Cox 
Reviewed-by: Hannes Reinicke 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

aacraid: Fix memory leak in aac_fib_map_free

2016-04-18T12:50:39+00:00

[ Upstream commit f88fa79a61726ce9434df9b4aede36961f709f17 ]

aac_fib_map_free() calls pci_free_consistent() without checking that
dev->hw_fib_va is not NULL and dev->max_fib_size is not zero.If they are
indeed NULL/0, this will result in a hang as pci_free_consistent() will
attempt to invalidate cache for the entire 64-bit address space
(which would take a very long time).

Fixed by adding a check to make sure that dev->hw_fib_va and
dev->max_fib_size are not NULL and 0 respectively.

Fixes: 9ad5204d6 - "[SCSI]aacraid: incorrect dma mapping mask during blinked recover or user initiated reset"
Cc: stable@vger.kernel.org

Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Tomas Henzl 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

aacraid: Fix RRQ overload

2016-04-18T12:50:39+00:00

[ Upstream commit 3f4ce057d51a9c0ed9b01ba693df685d230ffcae ]

The driver utilizes an array of atomic variables to keep track of IO
submissions to each vector. To submit an IO multiple threads iterate
through the array to find a vector which has empty slots to send an
IO. The reading and updating of the variable is not atomic, causing race
conditions when a thread uses a full vector to submit an IO.

Fixed by mapping each FIB to a vector, the submission path then uses
said vector to submit IO thereby removing the possibly of a race
condition.The vector assignment is started from 1 since vector 0 is
reserved for the use of AIF management FIBS.If the number of MSIx
vectors is 1 (MSI or INTx mode) then all the fibs are allocated to
vector 0.

Fixes: 495c0217 "aacraid: MSI-x support"
Cc: stable@vger.kernel.org # v4.1

Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Tomas Henzl 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

qla2xxx: Use pci_enable_msix_range() instead of pci_enable_msix()

2016-02-28T05:09:47+00:00

[ Upstream commit 84e32a06f4f8756ce9ec3c8dc7e97896575f0771 ]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Log message code 0x00c6 preserved, although it is reported
after successful call to pci_enable_msix_range(), not before
possibly unsuccessful call to pci_enable_msix(). Consumers
of the error code should not notice the difference.

Signed-off-by: Alexander Gordeev 
Acked-by: Chad Dupuis 
Cc: qla2xxx-upstream@qlogic.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin