From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:55026 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932121AbcDDIeN (ORCPT ); Mon, 4 Apr 2016 04:34:13 -0400 Date: Thu, 31 Mar 2016 15:47:21 +0200 From: Jan Kara To: Dave Chinner Cc: Jan Kara , linux-fsdevel@vger.kernel.org, Ross Zwisler , Dan Williams , "Wilcox, Matthew R" Subject: Re: DAX data corruption for mmaped and written files Message-ID: <20160331134721.GA10434@quack.suse.cz> References: <20160324131223.GJ4025@quack.suse.cz> <20160328223916.GB30721@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160328223916.GB30721@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue 29-03-16 09:39:16, Dave Chinner wrote: > On Thu, Mar 24, 2016 at 02:12:23PM +0100, Jan Kara wrote: > > Hello, > > > > yesterday I have been stress-testing mmap code with my new fault locking > > patches and I have found a data corruption issue when file is written both > > via mmap and standard write(2). The problem is following: > > > > CPU1 CPU2 > > dax_io() dax_fault() > > get_block() - allocates block > > ... get_block() - finds allocated block > > - zeroes it inside fs > > fault completese > > > > if (buffer_unwritten(bh) || buffer_new(bh)) -> new buffer > > dax_new_buf() -> zeroes buffer which may > > overwrite user data > > Which filesystem? XFS should be, in both cases, zeroing the > block entirely inside get_block() when it is first allocated. i.e we > should see: > > CPU1 CPU2 > dax_io() dax_fault() > get_block() - allocates block > - zeroes it inside fs > ... get_block() - finds allocated block > fault completes > > buffer returned is not new or unwritten. > > > > In some cases the race can also go the other way around and we lose data > > written by write. Yeah, correct. This is ext4 specific issue because ext4 doesn't return prezeroed blocks from get_block() callback used for dax_io(). Honza -- Jan Kara SUSE Labs, CR