On Wed, Oct 14, 2015 at 09:00:59PM -0600, Ross Zwisler wrote: > On Wed, Oct 14, 2015 at 01:30:22PM +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 and hole punching 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. > > > > Signed-off-by: Jan Kara <jack@xxxxxxxx> > > --- > > fs/ext4/ext4.h | 10 +++++++++ > > fs/ext4/file.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++-------- > > fs/ext4/inode.c | 27 +++++++++++++++++++---- > > fs/ext4/super.c | 1 + > > 4 files changed, 91 insertions(+), 13 deletions(-) > > I wonder if there are a few other operations in ext4_fallocate() that > we may need to protect in addition to ext4_punch_hole()? > > Do ext4_collapse_range(), ext4_insert_range() and maybe even ext4_zero_range() > need protection? Yes, they do. Anything that does direct extent manipulation needs to invalidate current mappings across the range and that requires page fault serialisation. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
