All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.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: Wed, 11 Apr 2018 12:06:48 -0400	[thread overview]
Message-ID: <x49d0z5pw13.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <20180409093211.GA30549@infradead.org> (Christoph Hellwig's message of "Mon, 9 Apr 2018 02:32:11 -0700")

Christoph Hellwig <hch@infradead.org> writes:

> On Fri, Apr 06, 2018 at 03:41:39PM -0700, Dan Williams wrote:
>> 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)?
>
> Sounds like a default.

Which do you turn off?  DAX or MAP_SYNC (or both)?

Systems that support ACPI versions earlier than 6.2 could provide
flush hint addresses.  In that case, we could assume no ADR, and turn
off MAP_SYNC, but still allow DAX.  Note that I'm not aware of any
hardware that actually falls into this category.

Platforms prior to 6.2 that don't support flush hints are currently
assumed to implement ADR.  This proposal would change that default.

>> Require opt-in when the user has trust in the hardware config that
>> the kernel can't verify?
>
> And that sounds like a good config nob ontop of that default.

Well, we could also make a white-list for known good platforms.  I
assume HPE's systems would be on that list.  Otherwise we'd have to cook
up udev rules, I guess?

Dan, is this something you're working on now?

-Jeff
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

  reply	other threads:[~2018-04-11 16:06 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
2018-04-09  9:32               ` Christoph Hellwig
2018-04-11 16:06                 ` Jeff Moyer [this message]
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=x49d0z5pw13.fsf@segfault.boston.devel.redhat.com \
    --to=jmoyer@redhat.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.