On Mon, Aug 31, 2015 at 12:59:44PM -0600, Ross Zwisler wrote: > For DAX msync we just need to flush the given range using > wb_cache_pmem(), which is now a public part of the PMEM API. This is wrong, because it still leaves fsync() broken on dax. Flushing dirty data to stable storage is the responsibility of the writeback infrastructure, not the VMA/mm infrasrtucture. For non-dax configurations, msync defers all that to vfs_fsync_range(), because it has to be implemented there for fsync() to work. Even for DAX, msync has to call vfs_fsync_range() for the filesystem to commit the backing store allocations to stable storage, so there's not getting around the fact msync is the wrong place to be flushing DAX mappings to persistent storage. I pointed this out almost 6 months ago (i.e. that fsync was broken) anf hinted at how to solve it. Fix fsync, and msync gets fixed for free: https://lists.01.org/pipermail/linux-nvdimm/2015-March/000341.html I've also reported to Willy that DAX write page faults don't work correctly, either. xfstests generic/080 exposes this: a read from a page followed immediately by a write to that page does not result in ->page_mkwrite being called on the write and so backing store is not allocated for the page, nor are the timestamps for the file updated. This will also result in fsync (and msync) not working properly. Fix fsync first - if fsync works then msync will work. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>