Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp251291pxf; Wed, 10 Mar 2021 05:42:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJyZOuA1Luld+Gwr/m5lmKbOQfnnrEciXRhzrEFI8HKNpEivG5ZVKXX71qDM5I0Gp+RI1KAN X-Received: by 2002:a05:6402:3c7:: with SMTP id t7mr3380956edw.196.1615383762336; Wed, 10 Mar 2021 05:42:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615383762; cv=none; d=google.com; s=arc-20160816; b=uEUJ+R6FGc/yxu3DAadOnCE69HQ6ptkNrD2c4duOeqmp+GwwVbtPJl4tQepGfOyWFB q5Fl9P2NZCStKB4dT82HRtxEahqEDvh9mc8iiNF3Uq5g+Oc50V8NGe9POOsSPocto+Qj krhBwvXOwJzFikC2U5CYsbGPj71oSP2Toi3TLESpTTGLXMLXEP7FiVlpVuXE1B6B9fQc sQl31PcTYm24TeQG9d08Hqf/HnBYme7kY9TA61HkXbWtmvIDJmlfIKtMmzzr4FRlI8dW 6CHgPJTqTopBCArcdTOxb6+3t2vU0uxrS0Ynru3d1IA1+fYV19yFE+jWjrAjDBmI/99j /Ptw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=rf+T63UoU0yere10A0ZlQWZ8iuadMB16XgMKXxmCQeE=; b=Z5UmWnxYyjYee3jQUy3G2NbWKjQwJPzVm9OWLjCYPJ870i4sAAQGGrAx3Cf9xAmeFL Bivsllr94C7GdejuV1FDvcT0B33KfBvrX8hRw09QmMVIl32dB15KYYKZ0eEckqrK0AF6 nCoW0iTfTDX24tGFBh36GX3jS/SCV6XMdZ+LVah3SV7yJi4xJ1yibB36NfHKZMpk64dd r6Y+5FCzUITBifcrudpSl6Sp59e6xo1kNTqJ8LyYHwpd9Uuq+IObsmOW9HeWY5LSk6Kt r3R0LAxz+td5eAXk05kC0kJytUy585ySTnX+kr4eJkAlFRgvi6ZPqPc/meBqD39iAOdT +jGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g8si12235478ejr.82.2021.03.10.05.42.16; Wed, 10 Mar 2021 05:42:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232814AbhCJNlS (ORCPT + 99 others); Wed, 10 Mar 2021 08:41:18 -0500 Received: from verein.lst.de ([213.95.11.211]:36524 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231867AbhCJNlP (ORCPT ); Wed, 10 Mar 2021 08:41:15 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 68A8D68D15; Wed, 10 Mar 2021 14:41:11 +0100 (CET) Date: Wed, 10 Mar 2021 14:41:10 +0100 From: Christoph Hellwig To: Dmitry Monakhov Cc: linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, hch@lst.de, Chaitanya.Kulkarni@wdc.com Subject: Re: [PATCH 1/1] nvme-pci: add the DISABLE_WRITE_ZEROES quirk for a Samsung PM1725a Message-ID: <20210310134110.GA13063@lst.de> References: <1615377076-3251-1-git-send-email-dmtrmonakhov@yandex-team.ru> <20210310132156.GA12145@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210310132156.GA12145@lst.de> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 10, 2021 at 02:21:56PM +0100, Christoph Hellwig wrote: > Can you try this patch instead? > > http://lists.infradead.org/pipermail/linux-nvme/2021-February/023183.html Actually, please try the patch below instead, it looks like our existing logic messes up the units: diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index e68a8c4ac5a6ea..1867fdf2205bd7 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -1963,30 +1963,18 @@ static void nvme_config_discard(struct gendisk *disk, struct nvme_ns *ns) blk_queue_max_write_zeroes_sectors(queue, UINT_MAX); } -static void nvme_config_write_zeroes(struct gendisk *disk, struct nvme_ns *ns) +/* + * Even though NVMe spec explicitly states that MDTS is not applicable to the + * write-zeroes, we are cautious and limit the size to the controllers + * max_hw_sectors value, which is based on the MDTS field and possibly other + * limiting factors. + */ +static void nvme_config_write_zeroes(struct request_queue *q, + struct nvme_ctrl *ctrl) { - u64 max_blocks; - - if (!(ns->ctrl->oncs & NVME_CTRL_ONCS_WRITE_ZEROES) || - (ns->ctrl->quirks & NVME_QUIRK_DISABLE_WRITE_ZEROES)) - return; - /* - * Even though NVMe spec explicitly states that MDTS is not - * applicable to the write-zeroes:- "The restriction does not apply to - * commands that do not transfer data between the host and the - * controller (e.g., Write Uncorrectable ro Write Zeroes command).". - * In order to be more cautious use controller's max_hw_sectors value - * to configure the maximum sectors for the write-zeroes which is - * configured based on the controller's MDTS field in the - * nvme_init_identify() if available. - */ - if (ns->ctrl->max_hw_sectors == UINT_MAX) - max_blocks = (u64)USHRT_MAX + 1; - else - max_blocks = ns->ctrl->max_hw_sectors + 1; - - blk_queue_max_write_zeroes_sectors(disk->queue, - nvme_lba_to_sect(ns, max_blocks)); + if ((ctrl->oncs & NVME_CTRL_ONCS_WRITE_ZEROES) && + !(ctrl->quirks & NVME_QUIRK_DISABLE_WRITE_ZEROES)) + blk_queue_max_write_zeroes_sectors(q, ctrl->max_hw_sectors); } static bool nvme_ns_ids_valid(struct nvme_ns_ids *ids) @@ -2158,7 +2146,7 @@ static void nvme_update_disk_info(struct gendisk *disk, set_capacity_and_notify(disk, capacity); nvme_config_discard(disk, ns); - nvme_config_write_zeroes(disk, ns); + nvme_config_write_zeroes(disk->queue, ns->ctrl); set_disk_ro(disk, (id->nsattr & NVME_NS_ATTR_RO) || test_bit(NVME_NS_FORCE_RO, &ns->flags));