On Thu, Oct 8, 2026 at 1:36 PM <[email protected]> wrote: > > diff --git a/fs/fuse/file.c b/fs/fuse/file.c > > index b5bef7b9e466e..77d7a54066e47 100644 > > --- a/fs/fuse/file.c > > +++ b/fs/fuse/file.c > > @@ -551,6 +551,17 @@ static int fuse_fsync(struct file *file, loff_t start, > > loff_t end, > > if (fuse_is_bad(inode)) > > return -EIO; > > > > + if (IS_DAX(inode) && !fuse_inode_vdax(inode)) { > > + /* > > + * Note: the DAX fault path calls this via > > dax_finish_sync_fault() > > + * and taking inode lock in that context is prohibited. > > + * > > + * FIXME: need to flush CPU caches for the DAX memory range > > + * FIXME: need to sync metadata to the server > > + */ > > + return 0; > > [Severity: High] > Can this cause silent data loss on fsync() for DAX extent-mapped files? > > When an application calls fsync() on a FUSE DAX extent-mapped file, this > bypasses flushing the CPU caches for the DAX memory range or syncing metadata > to the server, while still returning 0 (success). > > Because the operation falsely reports success, applications relying on fsync() > or MAP_SYNC (via dax_finish_sync_fault()) to ensure data durability will not > take fallback actions. Could this lead to silent data loss on a power failure > or crash?
John, what's up with CPU caches on mapped writes? Thanks, Miklos
