diff options
author | Alan Stern <stern@rowland.harvard.edu> | 2019-10-23 11:34:33 -0400 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2019-10-28 12:53:39 -0400 |
commit | 1186f86a71130a7635a20843e355bb880c7349b2 (patch) | |
tree | ab14281078ec5ed5739a4ea627079670cb85883e | |
parent | 9a976949613132977098fc49510b46fa8678d864 (diff) |
UAS: Revert commit 3ae62a42090f ("UAS: fix alignment of scatter/gather segments")
Commit 3ae62a42090f ("UAS: fix alignment of scatter/gather segments"),
copying a similar commit for usb-storage, attempted to solve a problem
involving scatter-gather I/O and USB/IP by setting the
virt_boundary_mask for mass-storage devices.
However, it now turns out that the analogous change in usb-storage
interacted badly with commit 09324d32d2a0 ("block: force an unlimited
segment size on queues with a virt boundary"), which was added later.
A typical error message is:
ehci-pci 0000:00:13.2: swiotlb buffer is full (sz: 327680 bytes),
total 32768 (slots), used 97 (slots)
There is no longer any reason to keep the virt_boundary_mask setting
in the uas driver. It was needed in the first place only for
handling devices with a block size smaller than the maxpacket size and
where the host controller was not capable of fully general
scatter-gather operation (that is, able to merge two SG segments into
a single USB packet). But:
High-speed or slower connections never use a bulk maxpacket
value larger than 512;
The SCSI layer does not handle block devices with a block size
smaller than 512 bytes;
All the host controllers capable of SuperSpeed operation can
handle fully general SG;
Since commit ea44d190764b ("usbip: Implement SG support to
vhci-hcd and stub driver") was merged, the USB/IP driver can
also handle SG.
Therefore all supported device/controller combinations should be okay
with no need for any special virt_boundary_mask. So in order to head
off potential problems similar to those affecting usb-storage, this
patch reverts commit 3ae62a42090f.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oneukum@suse.com>
CC: <stable@vger.kernel.org>
Acked-by: Christoph Hellwig <hch@lst.de>
Fixes: 3ae62a42090f ("UAS: fix alignment of scatter/gather segments")
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910231132470.1878-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-rw-r--r-- | drivers/usb/storage/uas.c | 20 |
1 files changed, 0 insertions, 20 deletions
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c index bf80d6f81f58..34538253f12c 100644 --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c | |||
@@ -789,30 +789,10 @@ static int uas_slave_alloc(struct scsi_device *sdev) | |||
789 | { | 789 | { |
790 | struct uas_dev_info *devinfo = | 790 | struct uas_dev_info *devinfo = |
791 | (struct uas_dev_info *)sdev->host->hostdata; | 791 | (struct uas_dev_info *)sdev->host->hostdata; |
792 | int maxp; | ||
793 | 792 | ||
794 | sdev->hostdata = devinfo; | 793 | sdev->hostdata = devinfo; |
795 | 794 | ||
796 | /* | 795 | /* |
797 | * We have two requirements here. We must satisfy the requirements | ||
798 | * of the physical HC and the demands of the protocol, as we | ||
799 | * definitely want no additional memory allocation in this path | ||
800 | * ruling out using bounce buffers. | ||
801 | * | ||
802 | * For a transmission on USB to continue we must never send | ||
803 | * a package that is smaller than maxpacket. Hence the length of each | ||
804 | * scatterlist element except the last must be divisible by the | ||
805 | * Bulk maxpacket value. | ||
806 | * If the HC does not ensure that through SG, | ||
807 | * the upper layer must do that. We must assume nothing | ||
808 | * about the capabilities off the HC, so we use the most | ||
809 | * pessimistic requirement. | ||
810 | */ | ||
811 | |||
812 | maxp = usb_maxpacket(devinfo->udev, devinfo->data_in_pipe, 0); | ||
813 | blk_queue_virt_boundary(sdev->request_queue, maxp - 1); | ||
814 | |||
815 | /* | ||
816 | * The protocol has no requirements on alignment in the strict sense. | 796 | * The protocol has no requirements on alignment in the strict sense. |
817 | * Controllers may or may not have alignment restrictions. | 797 | * Controllers may or may not have alignment restrictions. |
818 | * As this is not exported, we use an extremely conservative guess. | 798 | * As this is not exported, we use an extremely conservative guess. |