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 <hare@xxxxxxx> > Cc: Jeff Moyer <jmoyer@xxxxxxxxxx> > Cc: Christoph Hellwig <hch@xxxxxx> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > Cc: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> > Cc: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> > Acked-by: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> OK from my side, Reviewed-by: Johannes Thumshirn <jthumshirn@xxxxxxx> -- Johannes Thumshirn Storage jthumshirn@xxxxxxx +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 -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
