linux-stable.git/drivers/scsi/aacraid, branch linux-4.1.y

scsi: aacraid: Reorder Adapter status check

2017-05-17T19:06:59+00:00

[ Upstream commit c421530bf848604e97d0785a03b3fe2c62775083 ]

The driver currently checks the SELF_TEST_FAILED first and then
KERNEL_PANIC next. Under error conditions(boot code failure) both
SELF_TEST_FAILED and KERNEL_PANIC can be set at the same time.

The driver has the capability to reset the controller on an KERNEL_PANIC,
but not on SELF_TEST_FAILED.

Fixed by first checking KERNEL_PANIC and then the others.

Cc: stable@vger.kernel.org
Fixes: e8b12f0fb835223752 ([SCSI] aacraid: Add new code for PMC-Sierra's SRC base controller family)
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: David Carroll 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: aacraid: Fix INTx/MSI-x issue with older controllers

2017-03-06T22:31:14+00:00

[ Upstream commit 8af8e1c22f9994bb1849c01d66c24fe23f9bc9a0 ]

commit 78cbccd3bd68 ("aacraid: Fix for KDUMP driver hang")

caused a problem on older controllers which do not support MSI-x (namely
ASR3405,ASR3805). This patch conditionalizes the previous patch to
controllers which support MSI-x

Cc:  # v4.7+
Fixes: 78cbccd3bd68 ("aacraid: Fix for KDUMP driver hang")
Reported-by: Arkadiusz Miskiewicz 
Signed-off-by: Dave Carroll 
Reviewed-by: Raghava Aditya Renukunta 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

aacraid: Check size values after double-fetch from user

2016-08-24T18:12:51+00:00

[ Upstream commit fa00c437eef8dc2e7b25f8cd868cfa405fcc2bb3 ]

In aacraid's ioctl_send_fib() we do two fetches from userspace, one the
get the fib header's size and one for the fib itself. Later we use the
size field from the second fetch to further process the fib. If for some
reason the size from the second fetch is different than from the first
fix, we may encounter an out-of- bounds access in aac_fib_send(). We
also check the sender size to insure it is not out of bounds. This was
reported in https://bugzilla.kernel.org/show_bug.cgi?id=116751 and was
assigned CVE-2016-6480.

Reported-by: Pengfei Wang 
Fixes: 7c00ffa31 '[SCSI] 2.6 aacraid: Variable FIB size (updated patch)'
Cc: stable@vger.kernel.org
Signed-off-by: Dave Carroll 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

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

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

aacraid: driver version change

2015-04-09T23:57:01+00:00

Signed-off-by: Mahesh Rajashekhara 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Murthy Bhat 
Signed-off-by: James Bottomley

aacraid: AIF raw device remove support

2015-04-09T23:56:18+00:00

Signed-off-by: Mahesh Rajashekhara 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Murthy Bhat 
Signed-off-by: James Bottomley