• Dan Williams's avatar
    /dev/dax, core: file operations and dax-mmap · dee41079
    Dan Williams authored
    The "Device DAX" core enables dax mappings of performance / feature
    differentiated memory.  An open mapping or file handle keeps the backing
    struct device live, but new mappings are only possible while the device
    is enabled.   Faults are handled under rcu_read_lock to synchronize
    with the enabled state of the device.
    
    Similar to the filesystem-dax case the backing memory may optionally
    have struct page entries.  However, unlike fs-dax there is no support
    for private mappings, or mappings that are not backed by media (see
    use of zero-page in fs-dax).
    
    Mappings are always guaranteed to match the alignment of the dax_region.
    If the dax_region is configured to have a 2MB alignment, all mappings
    are guaranteed to be backed by a pmd entry.  Contrast this determinism
    with the fs-dax case where pmd mappings are opportunistic.  If userspace
    attempts to force a misaligned mapping, the driver will fail the mmap
    attempt.  See dax_dev_check_vma() for other scenarios that are rejected,
    like MAP_PRIVATE mappings.
    
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Acked-by: default avatar"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    dee41079
hugetlb.c 118 KB