From patchwork Wed Feb 13 04:37:42 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: 10809123 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 79F0814E1 for ; Wed, 13 Feb 2019 05:05:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 63D7E2C0B3 for ; Wed, 13 Feb 2019 05:05:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 53C1A2C160; Wed, 13 Feb 2019 05:05:03 +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 C87C42C0B3 for ; Wed, 13 Feb 2019 05:05:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726106AbfBMFFC (ORCPT ); Wed, 13 Feb 2019 00:05:02 -0500 Received: from esa4.hgst.iphmx.com ([216.71.154.42]:40347 "EHLO esa4.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725562AbfBMFFC (ORCPT ); Wed, 13 Feb 2019 00:05:02 -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=1550034302; x=1581570302; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=gxZbrDz3T4c7FDFz6lqvP/VrMjlvxApitpNPWIuhsp8=; b=XFzeKBQReyQg+lCUp1mmVaOZEgUgGmcOE602e0mMncNGrSyv3Qs91GYF xI+Cu/QAxjRs+uQcDRDI5bTKKyuVJE5RfMFpiUstHE0MNbTUDfCKroOAD Hss6848s5vGZRD1mSrly127Qn35wVSm8n9wlN3aNhBxtBtrhnfd2Xr3Wx DNLrZ4jPEMe4ZmdtwYhmSeYsThG0io+gxeugQdKnegCJiZnntn8LEL67U Z5O96T0c05OQHx4oXqKY5jBPpbuU5CfZH3HDB5QqffWzXxPAmETy4CfPJ ubqKg+k/J9zm55fcaVndZb5/S6A3WVWSgB081RXUZvCqWKUfbYr2X1iE3 g==; X-IronPort-AV: E=Sophos;i="5.58,364,1544457600"; d="scan'208";a="101065186" 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; 13 Feb 2019 13:05:02 +0800 Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep01.wdc.com with ESMTP; 12 Feb 2019 20:16:32 -0800 Received: from washi.fujisawa.hgst.com ([10.149.53.254]) by uls-op-cesaip02.wdc.com with ESMTP; 12 Feb 2019 20:37:57 -0800 From: Damien Le Moal To: linux-scsi@vger.kernel.org, "Martin K . Petersen" Cc: Masato Suzuki Subject: [PATCH] scsi: sd_zbc: Fix sd_zbc_report_zones() buffer allocation Date: Wed, 13 Feb 2019 13:37:42 +0900 Message-Id: <20190213043742.7032-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_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_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 commit '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 expected reply format rather than the generic struct blkzone size expected by blk_report_zones() makes more sense. Fixes: e76239a3748c ("block: add a report_zones method") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Signed-off-by: Masato Suzuki --- 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..fa75603a4090 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_sectors(disk->queue) << 9, + roundup((nrz + 1) * 64, 512)); buf = kmalloc(buflen, gfp_mask); if (!buf) return -ENOMEM;