04 Sep, 2016

1 commit

  • pgoff_to_phys() validates that both the starting address and the length
    of the mapping against the resource list. We need to check for a
    mapping size of PMD_SIZE not PAGE_SIZE in the pmd fault path.

    Signed-off-by: Dan Williams

    Dan Williams
     

07 Jul, 2016

1 commit

  • If devm_add_action() fails, we are explicitly calling the cleanup to free
    the resources allocated. Use the helper devm_add_action_or_reset()
    and return directly in case of error, since the cleanup function
    has been already called by the helper if there was any error.

    Reported-by: Sudip Mukherjee
    Signed-off-by: Vikas C Sajjan
    Reviewed-by: Johannes Thumshirn
    Signed-off-by: Dan Williams

    Sajjan, Vikas C
     

21 May, 2016

2 commits

  • 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
    Cc: Jeff Moyer
    Cc: Christoph Hellwig
    Cc: Andrew Morton
    Cc: Dave Hansen
    Cc: Ross Zwisler
    Acked-by: "Paul E. McKenney"
    Reviewed-by: Johannes Thumshirn
    Signed-off-by: Dan Williams

    Dan Williams
     
  • Device DAX is the device-centric analogue of Filesystem DAX
    (CONFIG_FS_DAX). It allows memory ranges to be allocated and mapped
    without need of an intervening file system. Device DAX is strict,
    precise and predictable. Specifically this interface:

    1/ Guarantees fault granularity with respect to a given page size (pte,
    pmd, or pud) set at configuration time.

    2/ Enforces deterministic behavior by being strict about what fault
    scenarios are supported.

    For example, by forcing MADV_DONTFORK semantics and omitting MAP_PRIVATE
    support device-dax guarantees that a mapping always behaves/performs the
    same once established. It is the "what you see is what you get" access
    mechanism to differentiated memory vs filesystem DAX which has
    filesystem specific implementation semantics.

    Persistent memory is the first target, but the mechanism is also
    targeted for exclusive allocations of performance differentiated memory
    ranges.

    This commit is limited to the base device driver infrastructure to
    associate a dax device with pmem range.

    Cc: Jeff Moyer
    Cc: Christoph Hellwig
    Cc: Andrew Morton
    Cc: Dave Hansen
    Cc: Ross Zwisler
    Reviewed-by: Johannes Thumshirn
    Signed-off-by: Dan Williams

    Dan Williams