From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 0/6] dax: Page invalidation fixes Date: Fri, 30 Sep 2016 01:59:05 -0700 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-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1474994615-29553-1-git-send-email-jack-AlSwsSmVLrQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Jan Kara Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org List-Id: linux-nvdimm@lists.01.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?