linux-toradex.git/drivers/scsi, branch v4.9.9

scsi: mpt3sas: fix hang on ata passthrough commands

2017-01-26T07:24:44+00:00

commit ffb58456589443ca572221fabbdef3db8483a779 upstream.

mpt3sas has a firmware failure where it can only handle one pass through
ATA command at a time.  If another comes in, contrary to the SAT
standard, it will hang until the first one completes (causing long
commands like secure erase to timeout).  The original fix was to block
the device when an ATA command came in, but this caused a regression
with

commit 669f044170d8933c3d66d231b69ea97cb8447338
Author: Bart Van Assche 
Date:   Tue Nov 22 16:17:13 2016 -0800

    scsi: srp_transport: Move queuecommand() wait code to SCSI core

So fix the original fix of the secure erase timeout by properly
returning SAM_STAT_BUSY like the SAT recommends.  The original patch
also had a concurrency problem since scsih_qcmd is lockless at that
point (this is fixed by using atomic bitops to set and test the flag).

[mkp: addressed feedback wrt. test_bit and fixed whitespace]

Fixes: 18f6084a989ba1b (mpt3sas: Fix secure erase premature termination)
Signed-off-by: James Bottomley 
Acked-by: Sreekanth Reddy 
Reviewed-by: Christoph Hellwig 
Reported-by: Ingo Molnar 
Tested-by: Ingo Molnar 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: ses: Fix SAS device detection in enclosure

2017-01-26T07:24:44+00:00

commit 9373eba6cfae48911b977d14323032cd5d161aae upstream.

The call to scsi_is_sas_rphy() needs to be made on the SAS end_device,
not on the SCSI device.

Fixes: 835831c57e9b ("ses: use scsi_is_sas_rphy instead of is_sas_attached")
Signed-off-by: Ewan D. Milne 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: James Bottomley 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

ibmvscsis: Fix max transfer length

2017-01-26T07:24:40+00:00

commit 387b978cb0d12cf3720ecb17e652e0a9991a08e2 upstream.

Current code incorrectly calculates the max transfer length, since
it is assuming a 4k page table, but ppc64 all run on 64k page tables.

Reported-by: Steven Royer 
Tested-by: Steven Royer 
Signed-off-by: Bryant G. Ly 
Signed-off-by: Bart Van Assche 
Signed-off-by: Greg Kroah-Hartman

ibmvscsis: Fix sleeping in interrupt context

2017-01-26T07:24:40+00:00

commit a5b0e4062fb225155189e593699bbfcd0597f8b5 upstream.

Currently, dma_alloc_coherent is being called with a GFP_KERNEL
flag which allows it to sleep in an interrupt context, need to
change to GFP_ATOMIC.

Tested-by: Steven Royer 
Reviewed-by: Michael Cyr 
Signed-off-by: Bryant G. Ly 
Signed-off-by: Bart Van Assche 
Signed-off-by: Greg Kroah-Hartman

qla2xxx: Fix crash due to null pointer access

2017-01-26T07:24:39+00:00

commit fc1ffd6cb38a1c1af625b9833c41928039e733f5 upstream.

During code inspection, while investigating following stack trace
seen on one of the test setup, we found out there was possibility
of memory leak becuase driver was not unwinding the stack properly.

This issue has not been reproduced in a test environment or on a
customer setup.

Here's stack trace that was seen.

[1469877.797315] Call Trace:
[1469877.799940]  [] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx]
[1469877.806980]  [] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx]
[1469877.814013]  [] ? __pm_runtime_resume+0x51/0xa0
[1469877.820265]  [] ? _raw_spin_lock_irqsave+0x25/0x90
[1469877.826776]  [] ? _raw_spin_unlock_irqrestore+0x6d/0x80
[1469877.833720]  [] ? preempt_count_sub+0xb1/0x100
[1469877.839885]  [] ? _raw_spin_unlock_irqrestore+0x4c/0x80
[1469877.846830]  [] local_pci_probe+0x4c/0xb0
[1469877.852562]  [] ? preempt_count_sub+0xb1/0x100
[1469877.858727]  [] pci_call_probe+0x89/0xb0

Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
Reviewed-by: Christoph Hellwig 
[ bvanassche: Fixed spelling in patch description ]
Signed-off-by: Bart Van Assche 
Signed-off-by: Greg Kroah-Hartman

ibmvscsis: Fix srp_transfer_data fail return code

2017-01-19T19:18:03+00:00

commit 7c9d8d0c41b3e24473ac7648a7fc2d644ccf08ff upstream.

If srp_transfer_data fails within ibmvscsis_write_pending, then
the most likely scenario is that the client timed out the op and
removed the TCE mapping. Thus it will loop forever retrying the
op that is pretty much guaranteed to fail forever. A better return
code would be EIO instead of EAGAIN.

Reported-by: Steven Royer 
Tested-by: Steven Royer 
Signed-off-by: Bryant G. Ly 
Signed-off-by: Bart Van Assche 
Signed-off-by: Greg Kroah-Hartman

scsi: mvsas: fix command_active typo

2017-01-12T10:39:29+00:00

commit af15769ffab13d777e55fdef09d0762bf0c249c4 upstream.

gcc-7 notices that the condition in mvs_94xx_command_active looks
suspicious:

drivers/scsi/mvsas/mv_94xx.c: In function 'mvs_94xx_command_active':
drivers/scsi/mvsas/mv_94xx.c:671:15: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context]

This was introduced when the mv_printk() statement got added, and leads
to the condition being ignored. This is probably harmless.

Changing '&&' to '&' makes the code look reasonable, as we check the
command bit before setting and printing it.

Fixes: a4632aae8b66 ("[SCSI] mvsas: Add new macros and functions")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: g_NCR5380: Fix release_region in error handling

2017-01-12T10:39:29+00:00

commit 7b93ca43b7e21fbe6fb1a6f4ecce4a2f70f424a0 upstream.

When a SW-configurable card is specified but not found, the driver
releases wrong region, causing the following message in kernel log:
Trying to free nonexistent resource <0000000000000000-000000000000000f>

Fix it by assigning base earlier.

Signed-off-by: Ondrej Zary 
Fixes: a8cfbcaec0c1 ("scsi: g_NCR5380: Stop using scsi_module.c")
Signed-off-by: Finn Thain 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

sg_write()/bsg_write() is not fit to be called under KERNEL_DS

2017-01-09T07:32:25+00:00

commit 128394eff343fc6d2f32172f03e24829539c5835 upstream.

Both damn things interpret userland pointers embedded into the payload;
worse, they are actually traversing those.  Leaving aside the bad
API design, this is very much _not_ safe to call with KERNEL_DS.
Bail out early if that happens.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

scsi: aacraid: remove wildcard for series 9 controllers

2017-01-09T07:32:22+00:00

commit ae2aae2421983f6f68eb7c4692624bc43ea50712 upstream.

Controllers with this PCI ID never shipped outside of
PMCS/Microsemi. Remove the ID from the aacraid driver. smartpqi is the
correct driver for these controllers.

[mkp: patch description]

Reviewed-by: Scott Teel 
Signed-off-by: Kevin Barnett 
Signed-off-by: Don Brace 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman