From: Dan Williams <dan.j.williams@intel.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH] dax: adding fsync/msync support for device DAX
Date: Fri, 6 Apr 2018 15:41:39 -0700 [thread overview]
Message-ID: <CAPcyv4g7kzRQqR63BFQXww5axjaZzdBb+pAGzC6TvfpxoTq+Sg@mail.gmail.com> (raw)
In-Reply-To: <20180406070310.GA16984@infradead.org>
On Fri, Apr 6, 2018 at 12:03 AM, Christoph Hellwig <hch@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
next prev parent reply other threads:[~2018-04-06 22:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-04 22:01 [PATCH] dax: adding fsync/msync support for device DAX Dave Jiang
2018-04-05 0:03 ` Dan Williams
2018-04-05 7:23 ` Christoph Hellwig
2018-04-05 7:56 ` Dan Williams
2018-04-05 8:01 ` Christoph Hellwig
2018-04-05 14:59 ` Jeff Moyer
2018-04-05 15:10 ` Christoph Hellwig
2018-04-05 22:17 ` Dan Williams
2018-04-06 7:03 ` Christoph Hellwig
2018-04-06 22:41 ` Dan Williams [this message]
2018-04-09 9:32 ` Christoph Hellwig
2018-04-11 16:06 ` Jeff Moyer
2018-04-11 16:27 ` Dan Williams
2018-04-11 17:27 ` Jeff Moyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPcyv4g7kzRQqR63BFQXww5axjaZzdBb+pAGzC6TvfpxoTq+Sg@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=hch@infradead.org \
--cc=linux-nvdimm@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.