linux-ext4 - Re: [RFC PATCH 0/7] dax, ext4: Synchronous page faults

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 15 Aug 2017 12:44:40 +0300
From:   Boaz Harrosh <boazh@...app.com>
To:     Dan Williams <dan.j.williams@...el.com>
CC:     Christoph Hellwig <hch@...radead.org>, Jan Kara <jack@...e.cz>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        Dave Chinner <david@...morbit.com>,
        <linux-xfs@...r.kernel.org>, Andy Lutomirski <luto@...nel.org>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        Amit Golander <amitg@...app.com>
Subject: Re: [RFC PATCH 0/7] dax, ext4: Synchronous page faults

On 15/08/17 12:06, Boaz Harrosh wrote:
> On 14/08/17 19:03, Dan Williams wrote:
>> On Mon, Aug 14, 2017 at 7:04 AM, Boaz Harrosh <boazh@...app.com> wrote:
>>>
>>> Thank you Jan, I'm patiently waiting for this MAP_SYNC flag since I asked for
>>> it in 2014. I'm so glad its time is finally do.
>>>
> 
> <>
> 
>>> 4] Once we have this flag. And properly implemented at least in one FS
>>>    and optionally in /dev/pmemX we no longer have any justification for
>>>    /dev/daxX and it can die a slow and happy death.
>>
>> I'm all for replacing /dev/dax with filesystem equivalent
>> functionality, but I don't think MAP_SYNC gets us fully there. That's
>> what the MAP_DIRECT proposal [1] is meant to address.
>>
> 
> OK This is true. Could you please summarise for us the exact semantics of both
> proposed flags?
> 
> That said I think the big difference is the movability of physical blocks
> underneath the mmap mapping. Now for swap files that is a problem. because
> of the deadlocks that can happen with memory needed if blocks start moving.
> But for an application like nvml? why does it care. Why can't an nvml image file
> not be cloned and COWed underneath the NVM application transparently.
> 

OK Sorry didn't do my homework. Struck this out, it is all about RDMA and friends
from an "immutable" file.

I'll go dig into this now. 

Thanks
Boaz

> Sorry for being slow but I don't see why you need MAP_DIRECT from user-mode
> If you have MAP_SYNC. Please advise
> 
> (not that the immutable patchset is not a very needed fixing)
> 
>> [1]: https://lkml.org/lkml/2017/8/13/160
>>
> 
> Thanks
> Boaz
>