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

scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error

2018-03-03T09:23:23+00:00

[ Upstream commit d1b8b2391c24751e44f618fcf86fb55d9a9247fd ]

When an I/O is returned with an srb_status of SRB_STATUS_INVALID_LUN
which has zero good_bytes it must be assigned an error. Otherwise the
I/O will be continuously requeued and will cause a deadlock in the case
where disks are being hot added and removed. sd_probe_async will wait
forever for its I/O to complete while holding scsi_sd_probe_domain.

Also returning the default error of DID_TARGET_FAILURE causes multipath
to not retry the I/O resulting in applications receiving I/O errors
before a failover can occur.

Signed-off-by: Cathy Avery 
Signed-off-by: Long Li 
Reviewed-by: Stephen Hemminger 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info

2018-02-28T09:18:30+00:00

commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.

The fcp_rsp_info structure as defined in the FC spec has an initial 3
bytes reserved field. The ibmvfc driver mistakenly defined this field as
4 bytes resulting in the rsp_code field being defined in what should be
the start of the second reserved field and thus always being reported as
zero by the driver.

Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a
single place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be
done in a followup patch.

Cc: 
Reported-by: Hannes Reinecke 
Signed-off-by: Tyrel Datwyler 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: advansys: fix uninitialized data access

2018-02-25T10:05:53+00:00

commit 44a5b977128c0ffff0654392b40f4c2ce72a619b upstream.

gcc-7.0.1 now warns about a previously unnoticed access of uninitialized
struct members:

drivers/scsi/advansys.c: In function 'AscMsgOutSDTR':
drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         ((ushort)s_buffer[i + 1] << 8) | s_buffer[i]);
                          ^
drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized]

The code has existed in this exact form at least since v2.6.12, and the
warning seems correct. This uses named initializers to ensure we
initialize all members of the structure.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: advansys: fix build warning for PCI=n

2018-02-25T10:05:52+00:00

commit f46e7cd36b5f2ce2bfb567e278a10ca717f85b84 upstream.

The advansys probe function tries to handle both ISA and PCI cases, each
hidden in an #ifdef when unused. This leads to a warning indicating that
when PCI is disabled we could be using uninitialized data:

drivers/scsi/advansys.c: In function  advansys_board_found :
drivers/scsi/advansys.c:11036:5: error:  ret  may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:10928:28: note:  ret  was declared here
drivers/scsi/advansys.c:11309:8: error:  share_irq  may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:10928:6: note:  share_irq  was declared here

This cannot happen in practice because the hardware in question only
exists for PCI, but changing the code to just error out here is better
for consistency and avoids the warning.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: smartpqi: allow static build ("built-in")

2018-02-22T14:43:47+00:00

commit dc2db1dc5fb9ab3a43b305c2720fee5278dbee2a upstream.

If CONFIG_SCSI_SMARTPQI=y then don't build this driver as a module.

Signed-off-by: Steffen Weber 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg

2018-02-03T16:05:40+00:00

[ Upstream commit 727535903bea924c4f73abb202c4b3e85fff0ca4 ]

_vreg_ is being dereferenced before it is null checked, hence there is a
potential null pointer dereference.

Fix this by moving the pointer dereference after _vreg_ has been null
checked.

This issue was detected with the help of Coccinelle.

Fixes: aa4976130934 ("ufs: Add regulator enable support")
Signed-off-by: Gustavo A. R. Silva 
Reviewed-by: Subhash Jadavani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path

2018-02-03T16:05:40+00:00

[ Upstream commit e4717292ddebcfe231651b5aff9fa19ca158d178 ]

As part of the scsi EH path, aacraid performs a reinitialization of the
adapter, which encompass freeing resources and IRQs, NULLifying lots of
pointers, and then initialize it all over again.  We've identified a
problem during the free IRQ portion of this path if CONFIG_DEBUG_SHIRQ
is enabled on kernel config file.

Happens that, in case this flag was set, right after free_irq()
effectively clears the interrupt, it checks if it was requested as
IRQF_SHARED. In positive case, it performs another call to the IRQ
handler on driver. Problem is: since aacraid currently free some
resources *before* freeing the IRQ, once free_irq() path calls the
handler again (due to CONFIG_DEBUG_SHIRQ), aacraid crashes due to NULL
pointer dereference with the following trace:

  aac_src_intr_message+0xf8/0x740 [aacraid]
  __free_irq+0x33c/0x4a0
  free_irq+0x78/0xb0
  aac_free_irq+0x13c/0x150 [aacraid]
  aac_reset_adapter+0x2e8/0x970 [aacraid]
  aac_eh_reset+0x3a8/0x5d0 [aacraid]
  scsi_try_host_reset+0x74/0x180
  scsi_eh_ready_devs+0xc70/0x1510
  scsi_error_handler+0x624/0xa20

This patch prevents the crash by changing the order of the
deinitialization in this path of aacraid: first we clear the IRQ, then
we free other resources. No functional change intended.

Signed-off-by: Guilherme G. Piccoli 
Reviewed-by: Raghava Aditya Renukunta 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

scsi: libiscsi: fix shifting of DID_REQUEUE host byte

2018-01-31T11:55:52+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: Greg Kroah-Hartman

scsi: hpsa: fix volume offline state

2018-01-23T18:57:05+00:00

commit eb94588dabec82e012281608949a860f64752914 upstream.

In a previous patch a hpsa_scsi_dev_t.volume_offline update line has
been removed, so let us put it back..

Fixes: 85b29008d8 (hpsa: update check for logical volume status)
Signed-off-by: Tomas Henzl 
Acked-by: Don Brace 
Signed-off-by: Martin K. Petersen 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

scsi: sg: disable SET_FORCE_LOW_DMA

2018-01-23T18:57:04+00:00

commit 745dfa0d8ec26b24f3304459ff6e9eacc5c8351b upstream.

The ioctl SET_FORCE_LOW_DMA has never worked since the initial git
check-in, and the respective setting is nowadays handled correctly. So
disable it entirely.

Signed-off-by: Hannes Reinecke 
Reviewed-by: Johannes Thumshirn 
Tested-by: Johannes Thumshirn 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman