"Universal Xport" LUN is used for in-band storage array management.

Cc: Sean Stewart <Sean.Stewart@netapp.com>
Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>
Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Cc: device-mapper development <dm-devel@redhat.com>
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: Sean Stewart <Sean.Stewart@netapp.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Commit b704f70ce200 ("SCSI: fix bug in scsi_dev_info_list matching")
changed the way vendor- and model-string matching was carried out in the
routine that looks up entries in a SCSI devinfo list.  The new matching
code failed to take into account the case of a maximum-length string; in
such cases it could end up testing for a terminating '\0' byte beyond
the end of the memory allocated to the string.  This out-of-bounds bug
was detected by UBSAN.

I don't know if anybody has actually encountered this bug.  The symptom
would be that a device entry in the blacklist might not be matched
properly if it contained an 8-character vendor name or a 16-character
model name.  Such entries certainly exist in scsi_static_device_list.

This patch fixes the problem by adding a check for a maximum-length
string before the '\0' test.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Fixes: b704f70ce200 ("SCSI: fix bug in scsi_dev_info_list matching")
Tested-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
CC: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Linux fails to boot as a guest with a QEMU CD-ROM:

[    4.439488] ata2.00: ATAPI: QEMU CD-ROM, 0.8.2, max UDMA/100
[    4.443649] ata2.00: configured for MWDMA2
[    4.450267] scsi 1:0:0:0: CD-ROM            QEMU     QEMU CD-ROM      0.8. PQ: 0 ANSI: 5
[    4.464317] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[    4.464319] ata2.00: BMDMA stat 0x5
[    4.464339] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in
[    4.464339]          Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
[    4.464341] ata2.00: status: { DRDY DRQ }
[    4.465864] ata2: soft resetting link
[    4.625971] ata2.00: configured for MWDMA2
[    4.628290] ata2: EH complete
[    4.646670] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[    4.646671] ata2.00: BMDMA stat 0x5
[    4.646683] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in
[    4.646683]          Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
[    4.646685] ata2.00: status: { DRDY DRQ }
[    4.648193] ata2: soft resetting link

...

Fix this by suppressing VPD inquiry for this device.

Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Reported-by: Jan Stancek <jstancek@redhat.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Add a new blacklist flag BLIST_SYNC_ALUA to instruct the
alua device handler to use synchronous command submission
for ALUA commands.

Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

The Marvell 91xx configuration device also needs to be on the VPD
blacklist.

[mkp: Match all revisions]

Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

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: <stable@vger.kernel.org>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Alexander Duyck <alexander.duyck@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Another iscsi target that cannot handle large IOs, but does not tell us
a limit.

The Synology iSCSI targets report:

Block limits VPD page (SBC):
  Write same no zero (WSNZ): 0
  Maximum compare and write length: 0 blocks
  Optimal transfer length granularity: 0 blocks
  Maximum transfer length: 0 blocks
  Optimal transfer length: 0 blocks
  Maximum prefetch length: 0 blocks
  Maximum unmap LBA count: 0
  Maximum unmap block descriptor count: 0
  Optimal unmap granularity: 0
  Unmap granularity alignment valid: 0
  Unmap granularity alignment: 0
  Maximum write same length: 0x0 blocks

and the size of the command it can handle seems to depend on how much
memory it can allocate at the time. This results in IO errors when
handling large IOs. This patch just has us use the old 1024 default
sectors for this target by adding it to the scsi blacklist. We do not
have good contacs with this vendors, so I have not been able to try and
fix on their side.

I have posted this a long while back, but it was not merged. This
version just fixes it up for merge/patch failures in the original
version.

Reported-by: Ancoron Luciferis <ancoron.luciferis@googlemail.com>
Reported-by: Michael Meyers <steltek@tcnnet.com>
Signed-off-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: <stable@vger.kernel.org> # 4.1+

The "compatible" matching algorithm used for looking up old-style
blacklist entries in a scsi_dev_info_list is buggy.  The core of the
algorithm looks like this:

		if (memcmp(devinfo->vendor, vendor,
			    min(max, strlen(devinfo->vendor))))
			/* not a match */

where max is the length of the device's vendor string after leading
spaces have been removed but trailing spaces have not.  Because of the
min() computation, either entry could be a proper substring of the
other and the code would still think that they match.

In the case originally reported, the device's vendor and product
strings were "Inateck " and "                ".  These matched against
the following entry in the global device list:

	{"", "Scanner", "1.80", BLIST_NOLUN}

because "" is a substring of "Inateck " and "" (the result of removing
leading spaces from the device's product string) is a substring of
"Scanner".  The mistaken match prevented the system from scanning and
finding the device's second Logical Unit.

This patch fixes the problem by making two changes.  First, the code
for leading-space removal is hoisted out of the loop.  (This means it
will sometimes run unnecessarily, but since a large percentage of all
lookups involve the "compatible" entries in global device list, this
should be an overall improvement.)  Second and more importantly, the
patch removes trailing spaces and adds a check to verify that the two
resulting strings are exactly the same length.  This prevents matches
where one entry is a proper substring of the other.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Giulio Bernardi <ugilio@gmail.com>
Tested-by: Giulio Bernardi <ugilio@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>