On 11/8/24 6:24 AM, Dan Williams wrote: > Asahi Lina wrote: > [..] >> I don't think that's how it actually works, at least on arm64. >> arch_wb_cache_pmem() calls dcache_clean_pop() which is either dc cvap or >> dc cvac. Those are trapped by HCR_EL2<TPC>, and that is never set by KVM. >> >> There was some discussion of this here: >> https://lore.kernel.org/all/20190702055937.3ffpwph7anvohmxu@US-160370MP2.local/ >> >> But I'm not sure that all really made sense then. >> >> msync() and fsync() should already provide persistence. Those end up >> calling vfs_fsync_range(), which becomes a FUSE fsync(), which fsyncs >> (or fdatasyncs) the whole file. What I'm not so sure is whether there >> are any other codepaths that also need to provide those guarantees which >> *don't* end up calling fsync on the VFS. For example, the manpages kind >> of imply munmap() syncs, though as far as I can tell that's not actually >> the case. If there are missing sync paths, then I think those might just >> be broken right now... > > IIRC, from the pmem persistence dicussions, if userspace fails to call > *sync then there is no obligation to flush on munmap() or close(). Some > filesystems layer on those guarantees, but the behavior is > implementation specific. Then I think your patch should be fine then, since there's nothing to do for writepages(). The syncing is handled via fsync() for FUSE/virtiofs and I don't think the dax_writeback_mapping_range() is actually doing anything in KVM anyway. ~~ Lina
