From patchwork Thu Jun 13 09:36:51 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yoshihiro Shimoda X-Patchwork-Id: 10992541 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 280EA13AF for ; Thu, 13 Jun 2019 15:46:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1835020564 for ; Thu, 13 Jun 2019 15:46:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 09A5C212D5; Thu, 13 Jun 2019 15:46:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=AC_FROM_MANY_DOTS,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 46EC120564 for ; Thu, 13 Jun 2019 15:46:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731781AbfFMPqs (ORCPT ); Thu, 13 Jun 2019 11:46:48 -0400 Received: from relmlor1.renesas.com ([210.160.252.171]:25554 "EHLO relmlie5.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731782AbfFMJhR (ORCPT ); Thu, 13 Jun 2019 05:37:17 -0400 X-IronPort-AV: E=Sophos;i="5.62,369,1554735600"; d="scan'208";a="18585683" Received: from unknown (HELO relmlir6.idc.renesas.com) ([10.200.68.152]) by relmlie5.idc.renesas.com with ESMTP; 13 Jun 2019 18:37:14 +0900 Received: from localhost.localdomain (unknown [10.166.17.210]) by relmlir6.idc.renesas.com (Postfix) with ESMTP id 2E2B3417857B; Thu, 13 Jun 2019 18:37:14 +0900 (JST) From: Yoshihiro Shimoda To: stern@rowland.harvard.edu, gregkh@linuxfoundation.org Cc: hch@lst.de, linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net, linux-renesas-soc@vger.kernel.org, Yoshihiro Shimoda Subject: [PATCH v2] usb-storage: Add a limitation for blk_queue_max_hw_sectors() Date: Thu, 13 Jun 2019 18:36:51 +0900 Message-Id: <1560418611-10239-1-git-send-email-yoshihiro.shimoda.uh@renesas.com> X-Mailer: git-send-email 2.7.4 Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This patch fixes an issue that the following error happens on swiotlb environment: xhci-hcd ee000000.usb: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 1338 (slots) On the kernel v5.1, block settings of a usb-storage with SuperSpeed were the following so that the block layer will allocate buffers up to 64 KiB, and then the issue didn't happen. max_segment_size = 65536 max_hw_sectors_kb = 1024 After the commit 09324d32d2a0 ("block: force an unlimited segment size on queues with a virt boundary") is applied, the block settings are the following. So, the block layer will allocate buffers up to 1024 KiB, and then the issue happens: max_segment_size = 4294967295 max_hw_sectors_kb = 1024 To fix the issue, the usb-storage driver checks the maximum size of a mapping for the device and then adjusts the max_hw_sectors_kb if required. After this patch is applied, the block settings will be the following, and then the issue doesn't happen. max_segment_size = 4294967295 max_hw_sectors_kb = 256 Fixes: 09324d32d2a0 ("block: force an unlimited segment size on queues with a virt boundary") Signed-off-by: Yoshihiro Shimoda Acked-by: Alan Stern --- Changes from v1: - Call blk_queue_max_hw_sectors() for the maximum size of mapping unconditionally to simplify the code by using read the value back from the queue in the end. - Add a comment on the code. - On v1, I got Reviewed-by from Christoph. But, I changed the code a little, I removed the Reviewed-by. drivers/usb/storage/scsiglue.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c index 59190d8..556bb4f 100644 --- a/drivers/usb/storage/scsiglue.c +++ b/drivers/usb/storage/scsiglue.c @@ -28,6 +28,8 @@ * status of a command. */ +#include +#include #include #include @@ -99,6 +101,7 @@ static int slave_alloc (struct scsi_device *sdev) static int slave_configure(struct scsi_device *sdev) { struct us_data *us = host_to_us(sdev->host); + struct device *dev = us->pusb_dev->bus->sysdev; /* * Many devices have trouble transferring more than 32KB at a time, @@ -129,6 +132,14 @@ static int slave_configure(struct scsi_device *sdev) } /* + * The max_hw_sectors should be up to maximum size of a mapping for + * the device. Otherwise, a DMA API might fail on swiotlb environment. + */ + blk_queue_max_hw_sectors(sdev->request_queue, + min_t(size_t, queue_max_hw_sectors(sdev->request_queue), + dma_max_mapping_size(dev) >> SECTOR_SHIFT)); + + /* * Some USB host controllers can't do DMA; they have to use PIO. * They indicate this by setting their dma_mask to NULL. For * such controllers we need to make sure the block layer sets