linux-stable.git/drivers/scsi, branch v3.2.100

libsas: remove unused ata_task_resp fields

2018-03-03T15:50:38+00:00

commit 95ac7fd189b7e81a200b4d00b2bb6669b31acf3a upstream.

Commit 1e34c838 "[SCSI] libsas: remove spurious sata control register
read/write" removed the routines to fake the presence of the sata
control registers, now remove the unused data structure fields to kill
any remaining confusion.

Acked-by: Jack Wang 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

scsi: use dma_get_cache_alignment() as minimum DMA alignment

2018-03-03T15:50:38+00:00

commit 90addc6b3c9cda0146fbd62a08e234c2b224a80c upstream.

In non-coherent DMA mode, kernel uses cache flushing operations to
maintain I/O coherency, so scsi's block queue should be aligned to the
value returned by dma_get_cache_alignment().  Otherwise, If a DMA buffer
and a kernel structure share a same cache line, and if the kernel
structure has dirty data, cache_invalidate (no writeback) will cause
data corruption.

Signed-off-by: Huacai Chen 
[hch: rebased and updated the comment and changelog]
Signed-off-by: Christoph Hellwig 
Signed-off-by: Martin K. Petersen 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

scsi: bfa: integer overflow in debugfs

2018-02-13T18:32:09+00:00

commit 3e351275655d3c84dc28abf170def9786db5176d upstream.

We could allocate less memory than intended because we do:

	bfad->regdata = kzalloc(len << 2, GFP_KERNEL);

The shift can overflow leading to a crash.  This is debugfs code so the
impact is very small.  I fixed the network version of this in March with
commit 13e2d5187f6b ("bna: integer overflow bug in debugfs").

Fixes: ab2a9ba189e8 ("[SCSI] bfa: add debugfs support")
Signed-off-by: Dan Carpenter 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Ben Hutchings

scsi: libiscsi: fix shifting of DID_REQUEUE host byte

2018-01-01T20:50:57+00:00

commit eef9ffdf9cd39b2986367bc8395e2772bc1284ba upstream.

The SCSI host byte should be shifted left by 16 in order to have
scsi_decide_disposition() do the right thing (.i.e. requeue the
command).

Signed-off-by: Johannes Thumshirn 
Fixes: 661134ad3765 ("[SCSI] libiscsi, bnx2i: make bound ep check common")
Cc: Lee Duncan 
Cc: Hannes Reinecke 
Cc: Bart Van Assche 
Cc: Chris Leech 
Acked-by: Lee Duncan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Ben Hutchings

scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP

2018-01-01T20:50:55+00:00

commit 28a0bc4120d38a394499382ba21d6965a67a3703 upstream.

SBC-4 states:

  "A MAXIMUM UNMAP LBA COUNT field set to a non-zero value indicates the
   maximum number of LBAs that may be unmapped by an UNMAP command"

  "A MAXIMUM WRITE SAME LENGTH field set to a non-zero value indicates
   the maximum number of contiguous logical blocks that the device server
   allows to be unmapped or written in a single WRITE SAME command."

Despite the spec being clear on the topic, some devices incorrectly
expect WRITE SAME commands with the UNMAP bit set to be limited to the
value reported in MAXIMUM UNMAP LBA COUNT in the Block Limits VPD.

Implement a blacklist option that can be used to accommodate devices
with this behavior.

Reported-by: Bill Kuzeja 
Reported-by: Ewan D. Milne 
Reviewed-by: Ewan D. Milne 
Tested-by: Laurence Oberman 
Signed-off-by: Martin K. Petersen 
[bwh: Backported to 3.2:
 - Keep using literals for SD_MAX_WS{16,10}_BLOCKS
 - Adjust context]
Signed-off-by: Ben Hutchings

scsi: lpfc: Don't return internal MBXERR_ERROR code from probe function

2018-01-01T20:50:48+00:00

commit 5c756065e47dc3e84b00577bd109f0a8e69903d7 upstream.

Internal error codes happen to be positive, thus the PCI driver core
won't treat them as failure, but we do. This would cause a crash later
on as lpfc_pci_remove_one() is called (e.g. as shutdown function).

Fixes: 6d368e532168 ("[SCSI] lpfc 8.3.24: Add resource extent support")
Signed-off-by: Stefano Brivio 
Reviewed-by: Johannes Thumshirn 
Acked-by: Dick Kennedy 
Signed-off-by: Martin K. Petersen 
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings

scsi: qla2xxx: Fix an integer overflow in sysfs code

2017-11-26T13:51:06+00:00

commit e6f77540c067b48dee10f1e33678415bfcc89017 upstream.

The value of "size" comes from the user.  When we add "start + size" it
could lead to an integer overflow bug.

It means we vmalloc() a lot more memory than we had intended.  I believe
that on 64 bit systems vmalloc() can succeed even if we ask it to
allocate huge 4GB buffers.  So we would get memory corruption and likely
a crash when we call ha->isp_ops->write_optrom() and ->read_optrom().

Only root can trigger this bug.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=194061

Fixes: b7cc176c9eb3 ("[SCSI] qla2xxx: Allow region-based flash-part accesses.")
Reported-by: shqking 
Signed-off-by: Dan Carpenter 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Ben Hutchings

qla2xxx: Add mutex around optrom calls to serialize accesses.

2017-11-26T13:51:06+00:00

commit 7a8ab9c840b5dff9bb70328338a86444ed1c2415 upstream.

Signed-off-by: Chad Dupuis 
Signed-off-by: Saurav Kashyap 
Signed-off-by: James Bottomley 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

qla2xxx: Corrections to returned sysfs error codes.

2017-11-26T13:51:06+00:00

commit 71dfe9e776878d9583d004edade55edc2bdac5eb upstream.

Correct the erroneous return codes introduced by the following patch:
"Return sysfs error codes appropriate to conditions".

Signed-off-by: Joe Carnuccio 
Signed-off-by: Chad Dupuis 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

scsi: aacraid: Fix command send race condition

2017-11-26T13:51:05+00:00

commit 1ae948fa4f00f3a2823e7cb19a3049ef27dd6947 upstream.

This fixes a potential race condition observed on Power systems.

Several places throughout the aacraid driver call aac_fib_send or
similar to send a command to the aacraid adapter, then check the return
code to determine if the command was actually sent to the adapter, then
update the phase field in the scsi command scratch pad area to track
that the firmware now owns this command.  However, there is nothing that
ensures that by the time the aac_fib_send function returns and we go to
write to the scsi command, that the command hasn't already completed and
the scsi command has been freed.  This was causing random crashes in the
TCP stack which was tracked down to be caused by memory that had been a
struct request + scsi_cmnd being now used for an skbuff. Memory
poisoning was enabled in the kernel to debug this which showed that the
last owner of the memory that had been freed was aacraid and that it was
a struct request.  The memory that was corrupted was the exact data
pattern of AAC_OWNER_FIRMWARE and it was at the same offset that aacraid
writes, which is scsicmd->SCp.phase. The patch below resolves this
issue.

Signed-off-by: Brian King 
Tested-by: Wen Xiong 
Reviewed-by: Dave Carroll 
Signed-off-by: Martin K. Petersen 
[bwh: Backported to 3.2:
 - Drop changes to aac_send_hba_fib()
 - Adjust context]
Signed-off-by: Ben Hutchings