Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1173140yba; Thu, 9 May 2019 11:59:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqzofT7jq6Jad26CdU/ucv6pe6uKdvRvdHVPvOTYbM4xCn9cpIg5riZhroX30HgIDVDhZJ9/ X-Received: by 2002:aa7:914d:: with SMTP id 13mr7706248pfi.149.1557428353636; Thu, 09 May 2019 11:59:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557428353; cv=none; d=google.com; s=arc-20160816; b=Ihe4ZaWtCQtNUyfrQZ6iwdrA8N5JMPaEofAK99u5XbBFPrq7wTtyUCV8XdvBId3kXj 46cWWBojsy1FxYaCSS6YzcAPnwxJFtQdMsq9h3hzS5gKAgioN8+4dujoIIvMr/GgMCJE Pixk5khAY0A49fSoCBKnExxC2lUNIaRsnd+GAY5Nwb25fouaIVBa+7ZSp3KTWQkVrVVd F4X1rtT4HeEJLCAEP3axAWJ97Iqd5EcPqtYUIEaztBvkz8sSlM4YQswHMOQ1vK8fnK4F g6wEFF9T0iancE9/YQb6QrePbKU3MYYqnoTbg/QYflElFpjHeBCPNA065UpO9K+23zgG GHQw== 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=ZY/cYmx/6tevvvmXOZjxwMs1VFOdOMtbmSWQsTA63EA=; b=vI0SYRgX1pKh0XH32a11T1la+ZZOj3VJZRBsJ56Fa5YO0c7QPOHB7ZnYTF1c5g0cKS Fmk2ntSzEuDiLzU/O+NrjGEXXJwA1fDrLPqHfrq3d2736bHgwNB50SIs3omqZx6jSOk1 Km/gD9SzHM3ag41Y4b1RX1m0TmQXDt5cBirfOGR9m2+KnyIRyi5JUWf/NcyN8gWcHFnK /ag0RS8bV63RKjkSY3Yy0V0l6U4jC8XkBBJMi+wygmJvtLzyZHnjsosmIUh3e7sb3gY3 975kZrXH4U9T/lpT1bFVX+TmZ8rV6K/iW8S8FgKJL0fXfNvMs4vylRHr0nu3MQ/InMzw gbxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vka7yY1h; 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 cn19si4796402plb.400.2019.05.09.11.58.57; Thu, 09 May 2019 11:59:13 -0700 (PDT) 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=vka7yY1h; 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 S1729056AbfEISyY (ORCPT + 99 others); Thu, 9 May 2019 14:54:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:49076 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729045AbfEISyU (ORCPT ); Thu, 9 May 2019 14:54:20 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 BCFA5204FD; Thu, 9 May 2019 18:54:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557428059; bh=HwTDDQgpdyLKymq762qog44ANmbDGP/fSirsRKzlApc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vka7yY1hGk8ejNNRjnINR3GTVxnsSQAgpgWHJF7jXvRMEq/Y1vEZMssBY0vqgoAfb fwV6AAKuj6kv1EZerunuCx63EjrYot02ooeL6QEYa+BFoe1U4OgOpYHDHgf3DFRL89 7E8lJV6fOMbTl0rrO3YPI5S6MjucaHaN/QCnC7pg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alan Stern , Seth Bollinger , Ming Lei Subject: [PATCH 5.1 11/30] usb-storage: Set virt_boundary_mask to avoid SG overflows Date: Thu, 9 May 2019 20:42:43 +0200 Message-Id: <20190509181253.129007884@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190509181250.417203112@linuxfoundation.org> References: <20190509181250.417203112@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 747668dbc061b3e62bc1982767a3a1f9815fcf0e upstream. The USB subsystem has always had an unusual requirement for its scatter-gather transfers: Each element in the scatterlist (except the last one) must have a length divisible by the bulk maxpacket size. This is a particular issue for USB mass storage, which uses SG lists created by the block layer rather than setting up its own. So far we have scraped by okay because most devices have a logical block size of 512 bytes or larger, and the bulk maxpacket sizes for USB 2 and below are all <= 512. However, USB 3 has a bulk maxpacket size of 1024. Since the xhci-hcd driver includes native SG support, this hasn't mattered much. But now people are trying to use USB-3 mass storage devices with USBIP, and the vhci-hcd driver currently does not have full SG support. The result is an overflow error, when the driver attempts to implement an SG transfer of 63 512-byte blocks as a single 3584-byte (7 blocks) transfer followed by seven 4096-byte (8 blocks) transfers. The device instead sends 31 1024-byte packets followed by a 512-byte packet, and this overruns the first SG buffer. Ideally this would be fixed by adding better SG support to vhci-hcd. But for now it appears we can work around the problem by asking the block layer to respect the maxpacket limitation, through the use of the virt_boundary_mask. Signed-off-by: Alan Stern Reported-by: Seth Bollinger Tested-by: Seth Bollinger CC: Ming Lei Cc: stable Signed-off-by: Greg Kroah-Hartman --- drivers/usb/storage/scsiglue.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) --- a/drivers/usb/storage/scsiglue.c +++ b/drivers/usb/storage/scsiglue.c @@ -65,6 +65,7 @@ static const char* host_info(struct Scsi static int slave_alloc (struct scsi_device *sdev) { struct us_data *us = host_to_us(sdev->host); + int maxp; /* * Set the INQUIRY transfer length to 36. We don't use any of @@ -74,20 +75,17 @@ static int slave_alloc (struct scsi_devi sdev->inquiry_len = 36; /* - * USB has unusual DMA-alignment requirements: Although the - * starting address of each scatter-gather element doesn't matter, - * the length of each element except the last must be divisible - * by the Bulk maxpacket value. There's currently no way to - * express this by block-layer constraints, so we'll cop out - * and simply require addresses to be aligned at 512-byte - * boundaries. This is okay since most block I/O involves - * hardware sectors that are multiples of 512 bytes in length, - * and since host controllers up through USB 2.0 have maxpacket - * values no larger than 512. - * - * But it doesn't suffice for Wireless USB, where Bulk maxpacket - * values can be as large as 2048. To make that work properly - * will require changes to the block layer. + * USB has unusual scatter-gather requirements: the length of each + * scatterlist element except the last must be divisible by the + * Bulk maxpacket value. Fortunately this value is always a + * power of 2. Inform the block layer about this requirement. + */ + maxp = usb_maxpacket(us->pusb_dev, us->recv_bulk_pipe, 0); + blk_queue_virt_boundary(sdev->request_queue, maxp - 1); + + /* + * Some host controllers may have alignment requirements. + * We'll play it safe by requiring 512-byte alignment always. */ blk_queue_update_dma_alignment(sdev->request_queue, (512 - 1));