]> git.baikalelectronics.ru Git - kernel.git/commit
dax: fix data corruption when fault races with write
authorJan Kara <jack@suse.cz>
Fri, 12 May 2017 22:46:57 +0000 (15:46 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Fri, 12 May 2017 22:57:16 +0000 (15:57 -0700)
commitef13552601b20b3bda6f32d907777d28130282f0
treee2305568ef383361e88607860d4a73a31213a7d1
parent24bddfe410d2dc1ad3ff64650337ca9e7b8efd56
dax: fix data corruption when fault races with write

Currently DAX read fault can race with write(2) in the following way:

CPU1 - write(2) CPU2 - read fault
dax_iomap_pte_fault()
  ->iomap_begin() - sees hole
dax_iomap_rw()
  iomap_apply()
    ->iomap_begin - allocates blocks
    dax_iomap_actor()
      invalidate_inode_pages2_range()
        - there's nothing to invalidate
  grab_mapping_entry()
  - we add zero page in the radix tree
    and map it to page tables

The result is that hole page is mapped into page tables (and thus zeros
are seen in mmap) while file has data written in that place.

Fix the problem by locking exception entry before mapping blocks for the
fault.  That way we are sure invalidate_inode_pages2_range() call for
racing write will either block on entry lock waiting for the fault to
finish (and unmap stale page tables after that) or read fault will see
already allocated blocks by write(2).

Fixes: 724fa8d602970d4e05b4c04731e1b5812eecc65c
Link: http://lkml.kernel.org/r/20170510085419.27601-5-jack@suse.cz
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-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