On Wed, Nov 03, 2021 at 11:21:39PM -0700, Dan Williams wrote: > The concern I have with dax_clear_poison() is that it precludes atomic > error clearing. atomic as in clear poison and write the actual data? Yes, that would be useful, but it is not how the Intel pmem support actually works, right? > Also, as Boris and I discussed, poisoned pages should > be marked NP (not present) rather than UC (uncacheable) [1]. This would not really have an affect on the series, right? But yes, that seems like the right thing to do. > With > those 2 properties combined I think that wants a custom pmem fault > handler that knows how to carefully write to pmem pages with poison > present, rather than an additional explicit dax-operation. That also > meets Christoph's requirement of "works with the intended direct > memory map use case". So we have 3 kinds of accesses to DAX memory: (1) user space mmap direct access. (2) iov_iter based access (could be from kernel or userspace) (3) open coded kernel access using ->direct_access One thing I noticed: (2) could also work with kernel memory or pages, but that doesn't use MC safe access. Which seems like a major independent of this discussion. I suspect all kernel access could work fine with a copy_mc_to_kernel helper as long as everyone actually uses it, which will cover the missing required bits of (2) and (3) together with something like the ->clear_poison series from Jane. We just need to think hard what we want to do for userspace mmap access. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
