On Fri, Apr 6, 2018 at 12:03 AM, Christoph Hellwig <h...@infradead.org> 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
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Reply via email to