FS DAX requires file systems to call into the DAX layout prior to unlinking inodes to ensure there is no ongoing DMA or other remote access to the direct mapped page. The fuse file system implements fuse_dax_break_layouts() to do this which includes a comment indicating that passing dmap_end == 0 leads to unmapping of the whole file.
However this is not true - passing dmap_end == 0 will not unmap anything before dmap_start, and further more dax_layout_busy_page_range() will not scan any of the range to see if there maybe ongoing DMA access to the range. Fix this by checking for dmap_end == 0 in fuse_dax_break_layouts() and pass the entire file range to dax_layout_busy_page_range(). Signed-off-by: Alistair Popple <apop...@nvidia.com> Fixes: 6ae330cad6ef ("virtiofs: serialize truncate/punch_hole and dax fault path") Cc: Vivek Goyal <vgo...@redhat.com> --- I am not at all familiar with the fuse file system driver so I have no idea if the comment is relevant or not and whether the documented behaviour for dmap_end == 0 is ever relied upon. However this seemed like the safest fix unless someone more familiar with fuse can confirm that dmap_end == 0 is never used. --- fs/fuse/dax.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/fuse/dax.c b/fs/fuse/dax.c index 12ef91d..501a097 100644 --- a/fs/fuse/dax.c +++ b/fs/fuse/dax.c @@ -693,6 +693,10 @@ int fuse_dax_break_layouts(struct inode *inode, u64 dmap_start, ret = __fuse_dax_break_layouts(inode, &retry, dmap_start, dmap_end); } while (ret == 0 && retry); + if (!dmap_end) { + dmap_start = 0; + dmap_end = LLONG_MAX; + } return ret; } -- git-series 0.9.1