On Fri, Jan 29, 2016 at 9:28 PM, Matthew Wilcox <willy@xxxxxxxxxxxxxxx> wrote: > On Fri, Jan 29, 2016 at 11:28:15AM -0700, Ross Zwisler wrote: >> I guess I need to go off and understand if we can have DAX mappings on such a >> device. If we can, we may have a problem - we can get the block_device from >> get_block() in I/O path and the various fault paths, but we don't have access >> to get_block() when flushing via dax_writeback_mapping_range(). We avoid >> needing it the normal case by storing the sector results from get_block() in >> the radix tree. > > I think we're doing it wrong by storing the sector in the radix tree; we'd > really need to store both the sector and the bdev which is too much data. > > If we store the PFN of the underlying page instead, we don't have this > problem. Instead, we have a different problem; of the device going > away under us. I'm trying to find the code which tears down PTEs when > the device goes away, and I'm not seeing it. What do we do about user > mappings of the device? > I deferred the dax tear down code until next cycle as Al rightly pointed out some needed re-works: https://lists.01.org/pipermail/linux-nvdimm/2016-January/003995.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
