Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp4490840ybx; Mon, 4 Nov 2019 14:17:44 -0800 (PST) X-Google-Smtp-Source: APXvYqwmZzge6hcBnny4nuaSUsfF1XWMnBnqQwmnDS5B9W8fRitE0KZvVXAtCq8oLknrSZ/kitYx X-Received: by 2002:a50:de0b:: with SMTP id z11mr4514254edk.33.1572905864287; Mon, 04 Nov 2019 14:17:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572905864; cv=none; d=google.com; s=arc-20160816; b=p4x4C60ca3VDaqPwL3m4FHMASnTdEbexROfokurfJ7aCcyQnRfT6hbJeGS+NM2ADM7 EI5PdrvhCTnjYEOkIs0qwP65i2CPaXrSw72WT2p7vYuSkzifUAbtVJN211Wc00JcZTfX Lj9DBSOGg5noc8NG579RAJJ0oUVGlERA5+DdLaNMVzLb4rbR3OekjnyfEMs5JHab5XKB AGbLddazWfu6JU8cSp8kQ9SUq8RoB7Kz+NxYCPEP924E6LaSjGGQ3YTL18WT9ZIp/OYv t7w6byCh97fmxTlb/sjJB9dTipitPWfTtcjKjYMMsL9DVn8EZjgrUL99AHnNg+pOMxYg R1WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=LDn37dTzhifOZ7lELM83/Eb2bFwKcaR5IO6ODecGtwc=; b=mHyY4E+MeRWYh2oVfP8wFmPChyccZwL10Lu24olLux6b2raN0VOin4pGxB0MXdbzHq Pt1yQcPoRvNevJq7WXxZ2gIIoUaxsCTjLD7V81grYT4GHy77YXhe/S83XwZ0Xv7+wdVw ZBzCUAdPdjqceD2JPOKHU8d8GFRztoDPot+g6FGSeAa3I4IBpRlTvp0AxQrSh5+LxbUJ 4BlOf9MmVEf++W90DVGuagSdAgiADEJ/zOp5WDxQgfNA+Hrtn2w9LMLezCwanmNVVRI9 C2s+DD7AYL6e7d05l6vG2/2yLsThROusUu7HL9bNlD9q31agL2EjYAR+VCQwRxPbKlU1 3sTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UeSCYyJa; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c11si4303938ejr.176.2019.11.04.14.17.21; Mon, 04 Nov 2019 14:17:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UeSCYyJa; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389845AbfKDWIg (ORCPT + 99 others); Mon, 4 Nov 2019 17:08:36 -0500 Received: from mail.kernel.org ([198.145.29.99]:41412 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390229AbfKDWIa (ORCPT ); Mon, 4 Nov 2019 17:08:30 -0500 Received: from localhost (6.204-14-84.ripe.coltfrance.com [84.14.204.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 24D3E2084D; Mon, 4 Nov 2019 22:08:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572905309; bh=4TiYdvVxUzCNJ4QExnV8+tw17p0jkR3fYFgZLjCIeBE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UeSCYyJaT8x1sCIHbFnGbdeQr8BhOHHSE6/SIAGcLl1pf3xUs35TOkldNY4TLLO+M 10KpRkfzgPCm+BLnfsnIeFsQ3BjJPXGwz5noTl7q7hn5ysgDPhTXtUaZJtVpql9yGr fopllGgeGLnaGYTonUy7vFnaA59Jp9/RelXG0Ru0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alan Stern , Oliver Neukum , Christoph Hellwig Subject: [PATCH 5.3 102/163] UAS: Revert commit 3ae62a42090f ("UAS: fix alignment of scatter/gather segments") Date: Mon, 4 Nov 2019 22:44:52 +0100 Message-Id: <20191104212147.452249094@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191104212140.046021995@linuxfoundation.org> References: <20191104212140.046021995@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Alan Stern commit 1186f86a71130a7635a20843e355bb880c7349b2 upstream. 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 CC: Oliver Neukum CC: Acked-by: Christoph Hellwig 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 --- drivers/usb/storage/uas.c | 20 -------------------- 1 file changed, 20 deletions(-) --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c @@ -789,30 +789,10 @@ static int uas_slave_alloc(struct scsi_d { struct uas_dev_info *devinfo = (struct uas_dev_info *)sdev->host->hostdata; - int maxp; sdev->hostdata = devinfo; /* - * We have two requirements here. We must satisfy the requirements - * of the physical HC and the demands of the protocol, as we - * definitely want no additional memory allocation in this path - * ruling out using bounce buffers. - * - * For a transmission on USB to continue we must never send - * a package that is smaller than maxpacket. Hence the length of each - * scatterlist element except the last must be divisible by the - * Bulk maxpacket value. - * If the HC does not ensure that through SG, - * the upper layer must do that. We must assume nothing - * about the capabilities off the HC, so we use the most - * pessimistic requirement. - */ - - maxp = usb_maxpacket(devinfo->udev, devinfo->data_in_pipe, 0); - blk_queue_virt_boundary(sdev->request_queue, maxp - 1); - - /* * The protocol has no requirements on alignment in the strict sense. * Controllers may or may not have alignment restrictions. * As this is not exported, we use an extremely conservative guess.