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:   Thu, 27 Jul 2017 10:09:07 -0400
From:   Jeff Moyer <jmoyer@...hat.com>
To:     Jan Kara <jack@...e.cz>
Cc:     <linux-fsdevel@...r.kernel.org>,
        Christoph Hellwig <hch@...radead.org>,
        linux-nvdimm@...ts.01.org, Dave Chinner <david@...morbit.com>,
        linux-xfs@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
        linux-ext4@...r.kernel.org
Subject: Re: [RFC PATCH 0/7] dax, ext4: Synchronous page faults

Jan Kara <jack@...e.cz> writes:

Hi, Jan,

Thanks for looking into this!

> There are couple of open questions with this implementation:
>
> 1) Is it worth the hassle?
> 2) Is S_SYNC good flag to use or should we use a new inode flag?
> 3) VM_FAULT_RO and especially passing of resulting 'pfn' from
>    dax_iomap_fault() through filesystem fault handler to dax_pfn_mkwrite() in
>    vmf->orig_pte is a bit of a hack. So far I'm not sure how to refactor
>    things to make this cleaner.

4) How does an application discover that it is safe to flush from
   userspace?

-Jeff