On Mon, Dec 21, 2015 at 9:05 AM, Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> wrote: > On Sat, Dec 19, 2015 at 10:37:46AM -0800, Dan Williams wrote: >> On Fri, Dec 18, 2015 at 9:22 PM, Ross Zwisler >> <ross.zwisler@xxxxxxxxxxxxxxx> wrote: [..] >> Hi Ross, I should have realized this sooner, but what guarantees that >> the address returned by RADIX_DAX_ADDR(entry) is still valid at this >> point? I think we need to store the sector in the radix tree and then >> perform a new dax_map_atomic() operation to either lookup a valid >> address or fail the sync request. Otherwise, if the device is gone >> we'll crash, or write into some other random vmalloc address space. > > Ah, good point, thank you. v4 of this series is based on a version of > DAX where we aren't properly dealing with PMEM device removal. I've got an > updated version that merges with your dax_map_atomic() changes, and I'll add > this change into v5 which I will send out today. Thank you for the > suggestion. > > One clarification, with the code as it is in v4 we are only doing > clflush/clflushopt/clwb instructions on the kaddr we've stored in the radix > tree, so I don't think that there is actually a risk of us doing a "write into > some other random vmalloc address space"? I think at worse we will end up > clflushing an address that either isn't mapped or has been remapped by someone > else. Or are you worried that the clflush would trigger a cache writeback to > a memory address where writes have side effects, thus triggering the side > effect? > > I definitely think it needs to be fixed, I'm just trying to make sure I > understood your comment. True, this would be flushing an address that was dirtied while valid. Should be ok in practice for now since dax is effectively limited to x86, but we should not be leaning on x86 details in an architecture generic implementation like this. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
