From patchwork Thu Feb 14 06:01:18 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Damien Le Moal X-Patchwork-Id: 10811861 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 4996013B5 for ; Thu, 14 Feb 2019 06:01:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 37F422DB9D for ; Thu, 14 Feb 2019 06:01:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2BDFC2DBA6; Thu, 14 Feb 2019 06:01:24 +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.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham 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 AD7152DB9D for ; Thu, 14 Feb 2019 06:01:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730816AbfBNGBX (ORCPT ); Thu, 14 Feb 2019 01:01:23 -0500 Received: from esa4.hgst.iphmx.com ([216.71.154.42]:16539 "EHLO esa4.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726407AbfBNGBX (ORCPT ); Thu, 14 Feb 2019 01:01:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1550124083; x=1581660083; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=V0bXwI2D3KaAMOmK2Ed+cuuTkQxRN+mwtn/sO8TXMGE=; b=cwYRr+TboDsj5miFatL2w9AuqRnIHgl9rPKmPnxaFXvPrO/xYhlcqhvY OcLzuXHJaQgvjanxGAsYai8aVUteWxYLGWJH4XaO9ieVTGK2g8PKhx0sL j+GlsWhe6X022ohu4mJ/ZAlJ5KkNHamSizDOAuHp1dXZZqDxzFTGgGMqY LX5xR51+/9JMbVYLX2LeBBUX8S3agl6os9WoGrX1DPMVniGjhrEwgdrwG IEmQ3hMftAY2v8UL3MEncyvlU6wetZ1d+NjDFL4RgPAJPVGtbMqeRkpXK m+kSi2nu6fSQdNFCnL5apztj14hh2x5sjwQ6da17YsgDKCwN/ED8Qh+CY A==; X-IronPort-AV: E=Sophos;i="5.58,367,1544457600"; d="scan'208";a="101212671" Received: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 14 Feb 2019 14:01:23 +0800 Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep01.wdc.com with ESMTP; 13 Feb 2019 21:39:55 -0800 Received: from washi.fujisawa.hgst.com ([10.149.53.254]) by uls-op-cesaip02.wdc.com with ESMTP; 13 Feb 2019 22:01:21 -0800 From: Damien Le Moal To: linux-scsi@vger.kernel.org, "Martin K . Petersen" , Masato Suzuki Subject: [PATCH v2] scsi: sd_zbc: Fix sd_zbc_report_zones() buffer allocation Date: Thu, 14 Feb 2019 15:01:18 +0900 Message-Id: <20190214060118.15255-1-damien.lemoal@wdc.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Masato Suzuki The function sd_zbc_do_report_zones() issues a REPORT ZONES command with a buffer size calculated based on the number of zones requested by the caller. This value should however not exceed the capabilities of the hardware maximum command size, that is, should not exceed the max_hw_sectors limit of the device. This problem leads to failures of report zones commands when re-validating disks with some SAS HBAs. Fix this by limiting a report zone command buffer size to the minimum of the device max_hw_sectors and calculated value based on the requested number of zones. This does not change the semantic of the report_zones file operation as report zones can always return less zone reports than requested. Short reports are handled using a loop execution of the report_zones file operation in the function blk_report_zones(). [Damien] Before patch 'e76239a3748c ("block: add a report_zones method")', report zones buffer allocation was limited to max_sectors when allocated in blk_report_zones(). This however does not consider the actual format of the device reply which is interface dependent. Limiting the allocation based on the size of the expected reply format rather than the size of the array of generic sturct blkzone passed by blk_report_zones() makes more sense. Fixes: e76239a3748c ("block: add a report_zones method") Cc: stable@vger.kernel.org Signed-off-by: Masato Suzuki Signed-off-by: Damien Le Moal --- Changes from v1: * Use queue_max_hw_sectors() instead of queue_max_sectors() drivers/scsi/sd_zbc.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c index fff86940388b..a340af797a85 100644 --- a/drivers/scsi/sd_zbc.c +++ b/drivers/scsi/sd_zbc.c @@ -142,10 +142,12 @@ int sd_zbc_report_zones(struct gendisk *disk, sector_t sector, return -EOPNOTSUPP; /* - * Get a reply buffer for the number of requested zones plus a header. - * For ATA, buffers must be aligned to 512B. + * Get a reply buffer for the number of requested zones plus a header, + * without exceeding the device maximum command size. For ATA disks, + * buffers must be aligned to 512B. */ - buflen = roundup((nrz + 1) * 64, 512); + buflen = min(queue_max_hw_sectors(disk->queue) << 9, + roundup((nrz + 1) * 64, 512)); buf = kmalloc(buflen, gfp_mask); if (!buf) return -ENOMEM;