On Fri 23-10-15 21:21:35, Ted Tso wrote: > On Thu, Oct 22, 2015 at 10:15:53AM +0200, Jan Kara wrote: > > Currently, page faults and hole punching are completely unsynchronized. > > This can result in page fault faulting in a page into a range that we > > are punching after truncate_pagecache_range() has been called and thus > > we can end up with a page mapped to disk blocks that will be shortly > > freed. Filesystem corruption will shortly follow. Note that the same > > race is avoided for truncate by checking page fault offset against > > i_size but there isn't similar mechanism available for punching holes. > > > > Fix the problem by creating new rw semaphore i_mmap_sem in inode and > > grab it for writing over truncate, hole punching, and other functions > > removing blocks from extent tree and for read over page faults. We > > cannot easily use i_data_sem for this since that ranks below transaction > > start and we need something ranking above it so that it can be held over > > the whole truncate / hole punching operation. Also remove various > > workarounds we had in the code to reduce race window when page fault > > could have created pages with stale mapping information. > > > > Signed-off-by: Jan Kara <jack@xxxxxxxx> > > This patch is causing ext4/001 to fail even using the standard 4k > non-DAX test configuration. You had mentioned that extent zeroing was > getting suppressed for DAX file systems, but it looks like it's > getting suppressed even in the non-DAX configuration: I'll verify this in detail but if I remember correctly, this was caused by some thing like that with my patches we don't bother to first write out pages that aregoing to be zeroed out shortly because that's pretty pointless. But as I said, I'll check again to be sure. Honza > > % kvm-xfstests -c 4k ext4/001 > ... > ext4/001 [21:11:29][ 7.796142] run fstests ext4/001 at 2015-10-23 21:11:29 > [21:11:32] - output mismatch (see /results/results-4k/ext4/001.out.bad) > --- tests/ext4/001.out 2015-10-18 23:46:49.000000000 -0400 > +++ /results/results-4k/ext4/001.out.bad 2015-10-23 21:11:32.104276540 -0400 > @@ -131,14 +131,10 @@ > 2: [32..39]: hole > daa100df6e6711906b61c9ab5aa16032 > 11. data -> hole -> data > -0: [0..7]: data > -1: [8..31]: unwritten > -2: [32..39]: data > +0: [0..39]: data > ... > (Run 'diff -u tests/ext4/001.out /results/results-4k/ext4/001.out.bad' to see the entire diff) > > > - Ted > -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
