From patchwork Tue Sep 27 16:43:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Kara X-Patchwork-Id: 9352323 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1778B60757 for ; Tue, 27 Sep 2016 16:43:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 08F7F28911 for ; Tue, 27 Sep 2016 16:43:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F22422926D; Tue, 27 Sep 2016 16:43:51 +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=0.8 required=2.0 tests=BAYES_50, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id C412328911 for ; Tue, 27 Sep 2016 16:43:51 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 3CE7E1A1E4D; Tue, 27 Sep 2016 09:43:51 -0700 (PDT) X-Original-To: linux-nvdimm@lists.01.org Delivered-To: linux-nvdimm@lists.01.org Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id ED8061A1E47 for ; Tue, 27 Sep 2016 09:43:49 -0700 (PDT) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8B73E75015; Tue, 27 Sep 2016 16:43:48 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id BD8941E10D9; Tue, 27 Sep 2016 18:43:42 +0200 (CEST) From: Jan Kara To: linux-fsdevel@vger.kernel.org Subject: [PATCH 3/6] ext4: Remove clearing of BH_New bit for zeroed blocks Date: Tue, 27 Sep 2016 18:43:32 +0200 Message-Id: <1474994615-29553-4-git-send-email-jack@suse.cz> X-Mailer: git-send-email 2.6.6 In-Reply-To: <1474994615-29553-1-git-send-email-jack@suse.cz> References: <1474994615-29553-1-git-send-email-jack@suse.cz> X-BeenThere: linux-nvdimm@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Linux-nvdimm developer list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jan Kara , linux-nvdimm@lists.01.org MIME-Version: 1.0 Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" X-Virus-Scanned: ClamAV using ClamSMTP So far we did not return BH_New buffers from ext4_dax_get_block() because that would trigger racy zeroing in DAX code. This zeroing is gone these days so we can remove the workaround. Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig --- fs/ext4/inode.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 87150122d361..7ccd6fd7819d 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3298,11 +3298,6 @@ int ext4_dax_get_block(struct inode *inode, sector_t iblock, if (ret < 0) return ret; } - /* - * At least for now we have to clear BH_New so that DAX code - * doesn't attempt to zero blocks again in a racy way. - */ - clear_buffer_new(bh_result); return 0; } #else