From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from bombadil.infradead.org ([198.137.202.9]:60310 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932835AbcI3I7G (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Fri, 30 Sep 2016 04:59:06 -0400
Date: Fri, 30 Sep 2016 01:59:05 -0700
From: Christoph Hellwig <hch@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, linux-nvdimm@ml01.01.org,
        Dan Williams <dan.j.williams@intel.com>,
        Ross Zwisler <ross.zwisler@linux.intel.com>
Subject: Re: [PATCH 0/6] dax: Page invalidation fixes
Message-ID: <20160930085905.GF22381@infradead.org>
References: <1474994615-29553-1-git-send-email-jack@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1474994615-29553-1-git-send-email-jack@suse.cz>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Tue, Sep 27, 2016 at 06:43:29PM +0200, Jan Kara wrote:
> Hello,
> 
> these patches fix races when invalidating hole pages in DAX mappings. See
> changelogs for details. The series is based on my patches to write-protect
> DAX PTEs because we really need to closely track dirtiness (and cleanness!)
> of radix tree entries in DAX mappings in order to avoid discarding valid
> dirty bits leading to missed cache flushes on fsync(2).

Except for the VM magic I don't feel qualified to review this looks fine
to me.  But don't we need to switch ext4 away from going through the DIO
path first before the limited invalidation is effective there?
Otherwise we'll still get the full range invalidation from
generic_file_direct_write?