Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1668545

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

Show all headers | View raw

On Sat, Jun 17, 2017 at 8:15 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Sat, Jun 17, 2017 at 4:50 PM, Andy Lutomirski <luto@kernel.org> wrote:
>> My other objection is that the syscall intentionally leaks a reference
>> to the file.  This means it needs overflow protection and it probably
>> shouldn't ever be allowed to use it without privilege.
>
> We only hold the one reference while S_DAXFILE is set, so I think the
> protection is there, and per Dave's original proposal this requires
> CAP_LINUX_IMMUTABLE.
>
>> Why can't the underlying issue be easily fixed, though?  Could
>> .page_mkwrite just make sure that metadata is synced when the FS uses
>> DAX?
>
> Yes, it most definitely could and that idea has been floated.
>
>> On a DAX fs, syncing metadata should be extremely fast.  This
>> could be conditioned on an madvise or mmap flag if performance might
>> be an issue.  As far as I know, this change alone should be
>> sufficient.
>
> The hang up is that it requires per-fs enabling as it needs to be
> careful to manage mmap_sem vs fs journal locks for example. I know the
> in-development NOVA [1] filesystem is planning to support this out of
> the gate. ext4 would be open to implementing it, but I think xfs is
> cold on the idea. Christoph originally proposed it here [2], before
> Dave went on to propose immutable semantics.

Hmm.  Given a choice between a very clean API that works without
privilege but is awkward to implement on XFS and an awkward-to-use
API, I'd personally choose the former.

Dave, even with the lock ordering issue, couldn't XFS implement
MAP_PMEM_AWARE by having .page_mkwrite work roughly like this:

if (metadata is dirty) {
  up_write(&mmap_sem);
  sync the metadata;
  down_write(&mmap_sem);
  return 0;  /* retry the fault */
} else {
  return whatever success code;
}

This might require returning VM_FAULT_RETRY instead of 0 and it might
require auditing the core mm code to make sure that it can handle
mmap_sem being dropped like this.  I don't see why it couldn't work in
principle, though.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH 0/2] daxfile: enable byte-addressable updates to pmem Dan Williams <dan.j.williams@intel.com> - 2017-06-17 03:30 +0200
  [RFC PATCH 2/2] mm, fs: daxfile,  an interface for byte-addressable updates to pmem Dan Williams <dan.j.williams@intel.com> - 2017-06-17 03:30 +0200
    Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Andy Lutomirski <luto@kernel.org> - 2017-06-17 18:30 +0200
      Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dan Williams <dan.j.williams@intel.com> - 2017-06-18 00:00 +0200
        Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Andy Lutomirski <luto@kernel.org> - 2017-06-18 02:00 +0200
          Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dan Williams <dan.j.williams@intel.com> - 2017-06-18 05:20 +0200
            Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Andy Lutomirski <luto@kernel.org> - 2017-06-18 07:10 +0200
              Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dave Chinner <david@fromorbit.com> - 2017-06-19 15:30 +0200
                Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Andy Lutomirski <luto@kernel.org> - 2017-06-19 17:30 +0200
            Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for         byte-addressable updates to pmem Christoph Hellwig <hch@lst.de> - 2017-06-18 10:20 +0200
              Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dan Williams <dan.j.williams@intel.com> - 2017-06-19 04:00 +0200

csiph-web