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

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

scsi: mac_esp: Fix PIO transfers for MESSAGE IN phase

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

commit 7640d91d285893a5cf1e62b2cd00f0884c401d93 upstream.

When in MESSAGE IN phase, the ESP device does not automatically
acknowledge each byte that is transferred by PIO. The mac_esp driver
neglects to explicitly ack them, which causes a timeout during messages
larger than one byte (e.g. tag bytes during reconnect). Fix this with an
ESP_CMD_MOK command after each byte.

The MESSAGE IN phase is also different in that each byte transferred
raises ESP_INTR_FDONE. So don't exit the transfer loop for this interrupt,
for this phase.

That resolves the "Reconnect IRQ2 timeout" error on those Macs which use
PIO transfers instead of PDMA. This patch also improves on the weak tests
for unexpected interrupts and phase changes during PIO transfers.

Tested-by: Stan Johnson 
Fixes: 02507a80b35e ("[PATCH] [SCSI] mac_esp: fix PIO mode, take 2")
Signed-off-by: Finn Thain 
Signed-off-by: Martin K. Petersen 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

scsi: advansys: remove #warning message

2017-11-11T13:34:50+00:00

The advansys driver was converted to the proper DMA API in linux-4.2, but
the 3.18-stable kernel still warns about this:

drivers/scsi/advansys.c:71:2: warning: #warning this driver is still not properly converted to the DMA API [-Wcpp]

The warning clearly is not helpful in 3.18 any more, it just clutters up
the build log. This removes the warning instead, and clarifies the
comment above it.

Cc: Hannes Reinecke 
Signed-off-by: Arnd Bergmann 
[bwh: Changed comment to say 3.2]
Signed-off-by: Ben Hutchings