• Ross Zwisler's avatar
    dax: fix PMD data corruption when fault races with write · 876f2946
    Ross Zwisler authored
    This is based on a patch from Jan Kara that fixed the equivalent race in
    the DAX PTE fault path.
    
    Currently DAX PMD read fault can race with write(2) in the following
    way:
    
    CPU1 - write(2)                 CPU2 - read fault
                                    dax_iomap_pmd_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 huge zero page to 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: 9f141d6e ("dax: Call ->iomap_begin without entry lock during dax fault")
    Link: http://lkml.kernel.org/r/20170510172700.18991-1-ross.zwisler@linux.intel.comSigned-off-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
    Reviewed-by: default avatarJan Kara <jack@suse.cz>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    876f2946
dax.c 40.5 KB