On Tue 17-11-15 17:41:55, Boylston, Brian wrote: > On Tue, Nov 10, 2015 at 2:51 PM, Jan Kara wrote: > > submitted. Also note that testing with 1 KB blocksize on ramdisk is broken > > since brd has buggy discard implementation - Jens has a fix queued. > > > > Change since v3: > > * Fixed ext4_dax_mmap_get_block() to not return buffer_new buffer and thus > > avoid racy zeroing in generic dax code > > * Fixed ext4_map_blocks() to zeroout blocks before inserting entry into > > extent status tree to avoid racy lookups of blocks. > > > > Changes since v2: > > * Fixed collaps range to truncate pagecache properly with blocksize < pagesize > > * Fixed assertion in ext4_get_blocks_overwrite > > > > Patch set description > > > > This series fixes a long standing problem of racing punch hole and page fault > > resulting in possible filesystem corruption or stale data exposure. We fix the > > problem by using a new inode-private rw_semaphore i_mmap_sem to synchronize > > page faults with truncate and punch hole operations. > > > > When having this exclusion, the only remaining problem with DAX implementation > > are races between two page faults zeroing out same block concurrently (where > > the data written after the first fault finishes are possibly overwritten by > > the second fault still doing zeroing). > > Is this still a problem for this version of the patch set? No, the patch set fixes this problem. The paragraph meant to say that first few patches fix hole punching issues and then a few patches fix this DAX issue. But the wording is strange, I agree. Honza -- 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
