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 <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
