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

sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes

2016-04-20T05:27:31+00:00

[ Upstream commit f08bb1e0dbdd0297258d0b8cd4dbfcc057e57b2a ]

During revalidate we check whether device capacity has changed before we
decide whether to output disk information or not.

The check for old capacity failed to take into account that we scaled
sdkp->capacity based on the reported logical block size. And therefore
the capacity test would always fail for devices with sectors bigger than
512 bytes and we would print several copies of the same discovery
information.

Avoid scaling sdkp->capacity and instead adjust the value on the fly
when setting the block device capacity and generating fake C/H/S
geometry.

Signed-off-by: Martin K. Petersen 
Cc: 
Reported-by: Hannes Reinecke 
Reviewed-by: Hannes Reinicke 
Reviewed-by: Ewan Milne 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

sg: fix dxferp in from_to case

2016-04-18T12:49:27+00:00

[ Upstream commit 5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 ]

One of the strange things that the original sg driver did was let the
user provide both a data-out buffer (it followed the sg_header+cdb)
_and_ specify a reply length greater than zero. What happened was that
the user data-out buffer was copied into some kernel buffers and then
the mid level was told a read type operation would take place with the
data from the device overwriting the same kernel buffers. The user would
then read those kernel buffers back into the user space.

From what I can tell, the above action was broken by commit fad7f01e61bf
("sg: set dxferp to NULL for READ with the older SG interface") in 2008
and syzkaller found that out recently.

Make sure that a user space pointer is passed through when data follows
the sg_header structure and command.  Fix the abnormal case when a
non-zero reply_len is also given.

Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6
Cc:  #v2.6.28+
Signed-off-by: Douglas Gilbert 
Reviewed-by: Ewan Milne 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

be2iscsi: set the boot_kset pointer to NULL in case of failure

2016-04-18T12:49:26+00:00

[ Upstream commit 84bd64993f916bcf86270c67686ecf4cea7b8933 ]

In beiscsi_setup_boot_info(), the boot_kset pointer should be set to
NULL in case of failure otherwise an invalid pointer dereference may
occur later.

Cc: 
Signed-off-by: Maurizio Lombardi 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Jitendra Bhivare 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

aacraid: Fix memory leak in aac_fib_map_free

2016-04-18T12:49:17+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

qla2xxx: Use pci_enable_msix_range() instead of pci_enable_msix()

2016-03-02T20:19:05+00:00

[ Upstream commit 84e32a06f4f8756ce9ec3c8dc7e97896575f0771 ]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Log message code 0x00c6 preserved, although it is reported
after successful call to pci_enable_msix_range(), not before
possibly unsuccessful call to pci_enable_msix(). Consumers
of the error code should not notice the difference.

Signed-off-by: Alexander Gordeev 
Acked-by: Chad Dupuis 
Cc: qla2xxx-upstream@qlogic.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

SCSI: Add Marvell Console to VPD blacklist

2016-03-02T20:18:57+00:00

[ Upstream commit 82c43310508eb19eb41fe7862e89afeb74030b84 ]

I have a Marvell 88SE9230 SATA Controller that has some sort of
integrated console SCSI device attached to one of the ports.

  ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
  ata14.00: ATAPI: MARVELL VIRTUALL, 1.09, max UDMA/66
  ata14.00: configured for UDMA/66
  scsi 13:0:0:0: Processor         Marvell  Console 1.01 PQ: 0 ANSI: 5

Sending it VPD INQUIRY command seem to always fail with following error:

  ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
  ata14.00: irq_stat 0x40000001
  ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 2 dma 16640 in
            Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
  ata14: hard resetting link

This has been minor annoyance (only error printed on dmesg) until commit
09e2b0b14690 ("scsi: rescan VPD attributes") added call to scsi_attach_vpd()
in scsi_rescan_device(). The commit causes the system to splat out
following errors continuously without ever reaching the UI:

  ata14.00: configured for UDMA/66
  ata14: EH complete
  ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
  ata14.00: irq_stat 0x40000001
  ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 6 dma 16640 in
            Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
  ata14: hard resetting link
  ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
  ata14.00: configured for UDMA/66
  ata14: EH complete
  ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
  ata14.00: irq_stat 0x40000001
  ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 7 dma 16640 in
            Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)

Without in-depth understanding of SCSI layer and the Marvell controller,
I suspect this happens because when the link goes down (because of an
error) we schedule scsi_rescan_device() which again fails to read VPD
data... ad infinitum.

Since VPD data cannot be read from the device anyway we prevent the SCSI
layer from even trying by blacklisting the device. This gets away the
error and the system starts up normally.

[mkp: Widened the match to all revisions of this device]

Cc: 
Signed-off-by: Mika Westerberg 
Reported-by: Kirill A. Shutemov 
Reported-by: Alexander Duyck 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi_dh_rdac: always retry MODE SELECT on command lock violation

2016-03-02T20:18:57+00:00

[ Upstream commit d2d06d4fe0f2cc2df9b17fefec96e6e1a1271d91 ]

If MODE SELECT returns with sense '05/91/36' (command lock violation)
it should always be retried without counting the number of retries.
During an HBA upgrade or similar circumstances one might see a flood
of MODE SELECT command from various HBAs, which will easily trigger
the sense code and exceed the retry count.

Cc: 
Signed-off-by: Hannes Reinecke 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

target: Remove first argument of target_{get,put}_sess_cmd()

2016-03-02T20:18:56+00:00

[ Upstream commit afc16604c06414223478df3e42301ab630b9960a ]

The first argument of these two functions is always identical
to se_cmd->se_sess. Hence remove the first argument.

Signed-off-by: Bart Van Assche 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Christoph Hellwig 
Cc: Andy Grover 
Cc: 
Cc: Felipe Balbi 
Cc: Michael S. Tsirkin 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Sasha Levin

qla2xxx: terminate exchange when command is aborted by LIO

2016-03-02T20:18:53+00:00

[ Upstream commit 7359df25a53386dd33c223672bbd12cb49d0ce4f ]

The newly introduced aborted_task TFO callback has to terminate
exchange with QLogic driver, since command is being deleted and
no status will be queued to the driver at a later point.

This patch also moves the burden of releasing one cmd refcount to
the aborted_task handler.

Changed iSCSI aborted_task logic to satisfy the above requirement.

Cc:  # v3.18+
Signed-off-by: Alexei Potashnik 
Acked-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Sasha Levin

qla2xxx: added sess generations to detect RSCN update races

2016-03-02T20:18:52+00:00

[ Upstream commit df673274fa4896f25f0bf348d2a3535d74b4cbec ]

RSCN processing in qla2xxx driver can run in parallel with ELS/IO
processing. As such the decision to remove disappeared fc port's
session could be stale, because a new login sequence has occurred
since and created a brand new session.

Previous mechanism of dealing with this by delaying deletion request
was prone to erroneous deletions if the event that was supposed to
cancel the deletion never arrived or has been delayed in processing.

New mechanism relies on a time-like generation counter to serialize
RSCN updates relative to ELS/IO updates.

Cc:  # v3.18+
Signed-off-by: Alexei Potashnik 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Sasha Levin