From patchwork Thu Jun 13 04:35:04 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yoshihiro Shimoda X-Patchwork-Id: 10992987 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 6B6C11515 for ; Thu, 13 Jun 2019 16:49:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5D0BC1FF82 for ; Thu, 13 Jun 2019 16:49:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 50140200DF; Thu, 13 Jun 2019 16:49:31 +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 E5BDF202A5 for ; Thu, 13 Jun 2019 16:49:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730399AbfFMQt0 (ORCPT ); Thu, 13 Jun 2019 12:49:26 -0400 Received: from relmlor2.renesas.com ([210.160.252.172]:2728 "EHLO relmlie6.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726771AbfFMEf3 (ORCPT ); Thu, 13 Jun 2019 00:35:29 -0400 X-IronPort-AV: E=Sophos;i="5.62,368,1554735600"; d="scan'208";a="18346413" Received: from unknown (HELO relmlir6.idc.renesas.com) ([10.200.68.152]) by relmlie6.idc.renesas.com with ESMTP; 13 Jun 2019 13:35:27 +0900 Received: from localhost.localdomain (unknown [10.166.17.210]) by relmlir6.idc.renesas.com (Postfix) with ESMTP id 16B164117758; Thu, 13 Jun 2019 13:35:27 +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] usb-storage: Add a limitation for blk_queue_max_hw_sectors() Date: Thu, 13 Jun 2019 13:35:04 +0900 Message-Id: <1560400504-26884-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 --- We investigated this issue on the following ML: https://marc.info/?l=linux-block&m=156033909218970&w=2 drivers/usb/storage/scsiglue.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c index 59190d8..89c3640 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); + unsigned int max_sectors = 0; /* 0 means no update required */ /* * Many devices have trouble transferring more than 32KB at a time, @@ -106,26 +109,34 @@ static int slave_configure(struct scsi_device *sdev) * are limiting both to 32K (64 sectores). */ if (us->fflags & (US_FL_MAX_SECTORS_64 | US_FL_MAX_SECTORS_MIN)) { - unsigned int max_sectors = 64; + max_sectors = 64; if (us->fflags & US_FL_MAX_SECTORS_MIN) max_sectors = PAGE_SIZE >> 9; - if (queue_max_hw_sectors(sdev->request_queue) > max_sectors) - blk_queue_max_hw_sectors(sdev->request_queue, - max_sectors); + if (queue_max_hw_sectors(sdev->request_queue) <= max_sectors) + max_sectors = 0; } else if (sdev->type == TYPE_TAPE) { /* * Tapes need much higher max_sector limits, so just * raise it to the maximum possible (4 GB / 512) and * let the queue segment size sort out the real limit. */ - blk_queue_max_hw_sectors(sdev->request_queue, 0x7FFFFF); + max_sectors = 0x7FFFFF; } else if (us->pusb_dev->speed >= USB_SPEED_SUPER) { /* * USB3 devices will be limited to 2048 sectors. This gives us * better throughput on most devices. */ - blk_queue_max_hw_sectors(sdev->request_queue, 2048); + max_sectors = 2048; + } + + if (max_sectors > 0) { + struct device *dev = us->pusb_dev->bus->sysdev; + size_t max_dma_sectors = dma_max_mapping_size(dev) >> + SECTOR_SHIFT; + + max_sectors = min_t(size_t, max_sectors, max_dma_sectors); + blk_queue_max_hw_sectors(sdev->request_queue, max_sectors); } /*