On Wed, May 18, 2016 at 01:56:22PM -0700, Dan Williams wrote: > 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 <[email protected]> > Cc: Jeff Moyer <[email protected]> > Cc: Christoph Hellwig <[email protected]> > Cc: Andrew Morton <[email protected]> > Cc: Dave Hansen <[email protected]> > Cc: Ross Zwisler <[email protected]> > Acked-by: "Paul E. McKenney" <[email protected]> > Signed-off-by: Dan Williams <[email protected]>
OK from my side, Reviewed-by: Johannes Thumshirn <[email protected]> -- Johannes Thumshirn Storage [email protected] +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
