On Fri, Apr 6, 2018 at 12:03 AM, Christoph Hellwig <[email protected]> wrote: > On Thu, Apr 05, 2018 at 03:17:17PM -0700, Dan Williams wrote: >> > That means IFF ADR can fail like this we can't treat it as stable >> > storage and we must not support MAP_SYNC or equivalent device dax >> > behavior, period. >> >> Makes sense, we won't pursue *sync() support on device-dax it doesn't fit. > > We still have other bits of this way of thinking in the tree as far as > I can tell, e.g. the nvdimm_flush calls in pmem_make_request and thus > should come up with a coherent strategy if we trust ADR, and if we don't > fully trust it how to mitigate it.
Yes, but the trust interface definition is what is missing, especially when we consider memmap=ss!nn and qemu-kvm. For example do we turn off DAX and/or MAP_SYNC on all platforms that don't provide a positive "I have ADR" indication (ACPI 6.2 Section 5.2.25.9 NFIT Platform Capabilities Structure)? Require opt-in when the user has trust in the hardware config that the kernel can't verify? _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
