Skip to content

Commit d75996d

Browse files
rhvgoyaldjbw
authored andcommitted
dax: dax_layout_busy_page() should not unmap cow pages
Vivek: "As of now dax_layout_busy_page() calls unmap_mapping_range() with last argument as 1, which says even unmap cow pages. I am wondering who needs to get rid of cow pages as well. I noticed one interesting side affect of this. I mount xfs with -o dax and mmaped a file with MAP_PRIVATE and wrote some data to a page which created cow page. Then I called fallocate() on that file to zero a page of file. fallocate() called dax_layout_busy_page() which unmapped cow pages as well and then I tried to read back the data I wrote and what I get is old data from persistent memory. I lost the data I had written. This read basically resulted in new fault and read back the data from persistent memory. This sounds wrong. Are there any users which need to unmap cow pages as well? If not, I am proposing changing it to not unmap cow pages. I noticed this while while writing virtio_fs code where when I tried to reclaim a memory range and that corrupted the executable and I was running from virtio-fs and program got segment violation." Dan: "In fact the unmap_mapping_range() in this path is only to synchronize against get_user_pages_fast() and force it to call back into the filesystem to re-establish the mapping. COW pages should be left untouched by dax_layout_busy_page()." Cc: <[email protected]> Fixes: 5fac740 ("mm, fs, dax: handle layout changes to pinned dax mappings") Signed-off-by: Vivek Goyal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Williams <[email protected]>
1 parent e21a712 commit d75996d

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

fs/dax.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -600,7 +600,7 @@ struct page *dax_layout_busy_page(struct address_space *mapping)
600600
* guaranteed to either see new references or prevent new
601601
* references from being established.
602602
*/
603-
unmap_mapping_range(mapping, 0, 0, 1);
603+
unmap_mapping_range(mapping, 0, 0, 0);
604604

605605
xas_lock_irq(&xas);
606606
xas_for_each(&xas, entry, ULONG_MAX) {

0 commit comments

Comments
 (0)