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

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

qla2xxx: Mark port lost when we receive an RSCN for it.

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

[ Upstream commit ef86cb2059a14b4024c7320999ee58e938873032 ]

Signed-off-by: Chad Dupuis 
Signed-off-by: Saurav Kashyap 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

qla2xxx: Abort stale cmds on qla_tgt_wq when plogi arrives

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

[ Upstream commit daddf5cf9b5c68b81b2bb7133f1dd0fda4552d0b ]

cancel any commands from initiator's s_id that are still waiting
on qla_tgt_wq when PLOGI arrives.

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: drop cmds/tmrs arrived while session is being deleted

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

[ Upstream commit e52a8b45b9c782937f74b701f8c656d4e5619eb5 ]

If a new initiator (different WWN) shows up on the same fcport, old
initiator's session is scheduled for deletion. But there is a small
window between it being marked with QLA_SESS_DELETION_IN_PROGRESS
and qlt_unret_sess getting called when new session's commands will
keep finding old session in the fcport map.

This patch drops cmds/tmrs if they find session in the progress of
being deleted.

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: delay plogi/prli ack until existing sessions are deleted

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

[ Upstream commit a6ca88780dd66b0700d89419abd17b6b4bb49483 ]

- keep qla_tgt_sess object on the session list until it's freed

- modify use of sess->deleted flag to differentiate delayed
  session deletion that can be cancelled from irreversible one:
  QLA_SESS_DELETION_PENDING vs QLA_SESS_DELETION_IN_PROGRESS

- during IN_PROGRESS deletion all newly arrived commands and TMRs will
  be rejected, existing commands and TMRs will be terminated when
  given by the core to the fabric or simply dropped if session logout
  has already happened (logout terminates all existing exchanges)

- new PLOGI will initiate deletion of the following sessions
  (unless deletion is already IN_PROGRESS):
  - with the same port_name (with logout)
  - different port_name, different loop_id but the same port_id
    (with logout)
  - different port_name, different port_id, but the same loop_id
    (without logout)

- additionally each new PLOGI will store imm notify iocb in the
  same port_name session being deleted. When deletion process
  completes this iocb will be acked. Only the most recent PLOGI
  iocb is stored. The older ones will be terminated when replaced.

- new PRLI will initiate deletion of the following sessions
  (unless deletion is already IN_PROGRESS):
  - different port_name, different port_id, but the same loop_id
   (without logout)

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