Received: by 10.213.65.68 with SMTP id h4csp2423873imn; Mon, 2 Apr 2018 07:20:37 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/oujEDI1VN27a+JFAHIMcC6S5PMomVfL5P3jYxWLXIgCRpyzB2Fnpbopsz/H6wUrRGNMJY X-Received: by 10.98.253.9 with SMTP id p9mr7429147pfh.152.1522678837047; Mon, 02 Apr 2018 07:20:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522678837; cv=none; d=google.com; s=arc-20160816; b=ZBLCbAakqapyFShsi7rQ5VjmNE3np8xXOLL5Khqt0m0QSne6tuifa+mkC/uWQCatBf FBgMVkQwAJk+3CyXLlomVcNs1dyoxEFJAb9qzdAzFOxh8dccrlPXq7Uj4tYkpyEthFnB DqgMl11TEsp3N+I42+hJWD3WmfIv9WNQU7d0AhZEm3wLLSlrVS/AJFztxRvkoLYBjGxm 3j1suxw4D+GsSX0EyNREkF96fmI4zTdPVg/BNry2/2Y8luq/GppSosj00nCUVrtSjhKs YDqeyGVEQY/DVmdRi7bfLSCemVrg2QKIbfB7IILrNTOacvoQS+kzhvStXTUZ7MhfZ8Z6 9Edg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=Xz3jHpOmvY9lJVCMlb4TvjgS5IMZ4jR9bvaKqVslpdo=; b=so2fLyOZDegs0dOWC8gDkpc7eoIey6a5oR2+lxT4DkRfXy1s+7h6SuZtRRbKwgdbgg xq7AJe1L98hrE80KoBOW1fZvPcca34j/mlzGqSaREiavy0cQXpg3T0EoeKuvGr+vTGrR lGI4y0OGapfKPghY3SVWFG/pH9QTdcfvnQAf0i+pI6hEja58WMfSSpvO5TWBFzV2TDUi A+yHbUoeDUeKt2DOi1fil+dgTsxAkF0qu0W01ImmlzXjy5JJEGtDzfuTrNICy2IrfhFm IDVEmkxslx1OLV65sDwxSfSBomdbltTxem1d9VGEkDtOiKLKucwPk/1SIsTAGGKU99Dy p8oQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q74si298455pfg.295.2018.04.02.07.20.23; Mon, 02 Apr 2018 07:20:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752065AbeDBOTG (ORCPT + 99 others); Mon, 2 Apr 2018 10:19:06 -0400 Received: from mga03.intel.com ([134.134.136.65]:12098 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751418AbeDBOTF (ORCPT ); Mon, 2 Apr 2018 10:19:05 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Apr 2018 07:19:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,395,1517904000"; d="scan'208";a="29487120" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by fmsmga008.fm.intel.com with ESMTP; 02 Apr 2018 07:19:04 -0700 Date: Mon, 2 Apr 2018 08:21:42 -0600 From: Keith Busch To: Rodrigo Rosatti Galvao Cc: chaitany kulkarni , Sagi Grimberg , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, hch@lst.de, Chaitanya Kulkarni Subject: Re: [PATCH] nvmet: fix nvmet_execute_write_zeroes function Message-ID: <20180402142141.GC28945@localhost.localdomain> References: <1522444730-2060-1-git-send-email-rosattig@linux.vnet.ibm.com> <20180330212439.GA28945@localhost.localdomain> <93622938-f532-b8ac-2bca-fe40ed759e71@linux.vnet.ibm.com> <8a3d1471-571d-3352-1414-bf2051e2ebb9@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a3d1471-571d-3352-1414-bf2051e2ebb9@linux.vnet.ibm.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 02, 2018 at 10:47:10AM -0300, Rodrigo Rosatti Galvao wrote: > One thing that I just forgot to explain previously, but I think its > relevant: > > 1. The command is failing with 4k logical block size, but works with 512B > > 2. With the patch, the command is working for both 512B and 4K. While you're not getting errors with your patch, you're not zeroing out the requested blocks, so that's a data corruption. The issue is the +1 is in the wrong place. It needs to be added to the native format prior to converting it to a 512b sector count. Do you want to resend with that change?