mm: fix data corruption due to stale mmap reads
authorJan Kara <jack@suse.cz>
Fri, 12 May 2017 22:46:50 +0000 (15:46 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Fri, 12 May 2017 22:57:15 +0000 (15:57 -0700)
Currently, we didn't invalidate page tables during invalidate_inode_pages2()
for DAX.  That could result in e.g. 2MiB zero page being mapped into
page tables while there were already underlying blocks allocated and
thus data seen through mmap were different from data seen by read(2).
The following sequence reproduces the problem:

 - open an mmap over a 2MiB hole

 - read from a 2MiB hole, faulting in a 2MiB zero page

 - write to the hole with write(3p). The write succeeds but we
   incorrectly leave the 2MiB zero page mapping intact.

 - via the mmap, read the data that was just written. Since the zero
   page mapping is still intact we read back zeroes instead of the new
   data.

Fix the problem by unconditionally calling invalidate_inode_pages2_range()
in dax_iomap_actor() for new block allocations and by properly
invalidating page tables in invalidate_inode_pages2_range() for DAX
mappings.

Fixes: c6dcf52c23d2d3fb5235cec42d7dd3f786b87d55
Link: http://lkml.kernel.org/r/20170510085419.27601-3-jack@suse.cz
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/dax.c
mm/truncate.c

index 38deebb8c86e87de16ded1fb1efd92c7e42382e0..123d9903c77d859c1ecfa79022ef66c68ce294c2 100644 (file)
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1015,7 +1015,7 @@ dax_iomap_actor(struct inode *inode, loff_t pos, loff_t length, void *data,
         * into page tables. We have to tear down these mappings so that data
         * written by write(2) is visible in mmap.
         */
         * into page tables. We have to tear down these mappings so that data
         * written by write(2) is visible in mmap.
         */
-       if ((iomap->flags & IOMAP_F_NEW) && inode->i_mapping->nrpages) {
+       if (iomap->flags & IOMAP_F_NEW) {
                invalidate_inode_pages2_range(inode->i_mapping,
                                              pos >> PAGE_SHIFT,
                                              (end - 1) >> PAGE_SHIFT);
                invalidate_inode_pages2_range(inode->i_mapping,
                                              pos >> PAGE_SHIFT,
                                              (end - 1) >> PAGE_SHIFT);
index 706cff171a15323aaba9e7ebc502273e0145c4ed..6479ed2afc53fb9dd8d9719051ea77e7a5b200af 100644 (file)
@@ -686,7 +686,17 @@ int invalidate_inode_pages2_range(struct address_space *mapping,
                cond_resched();
                index++;
        }
                cond_resched();
                index++;
        }
-
+       /*
+        * For DAX we invalidate page tables after invalidating radix tree.  We
+        * could invalidate page tables while invalidating each entry however
+        * that would be expensive. And doing range unmapping before doesn't
+        * work as we have no cheap way to find whether radix tree entry didn't
+        * get remapped later.
+        */
+       if (dax_mapping(mapping)) {
+               unmap_mapping_range(mapping, (loff_t)start << PAGE_SHIFT,
+                                   (loff_t)(end - start + 1) << PAGE_SHIFT, 0);
+       }
 out:
        cleancache_invalidate_inode(mapping);
        return ret;
 out:
        cleancache_invalidate_inode(mapping);
        return ret;