Re: [PATCH v2 2/3] mm, dax: add VM_DAX flag for DAX VMAs

[Dan Williams]

On Thu, Sep 15, 2016 at 7:04 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
> On Thu, Sep 15, 2016 at 6:24 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>> On Thu, Sep 15, 2016 at 05:16:42PM -0700, Dan Williams wrote:
>>> On Thu, Sep 15, 2016 at 4:07 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>>> > On Thu, Sep 15, 2016 at 10:01:03AM -0700, Dan Williams wrote:
>>> >> On Thu, Sep 15, 2016 at 1:26 AM, Christoph Hellwig <hch@xxxxxx> wrote:
>>> >> > On Wed, Sep 14, 2016 at 11:54:38PM -0700, Dan Williams wrote:
>>> >> >> The DAX property, page cache bypass, of a VMA is only detectable via the
>>> >> >> vma_is_dax() helper to check the S_DAX inode flag.  However, this is
>>> >> >> only available internal to the kernel and is a property that userspace
>>> >> >> applications would like to interrogate.
>>> >> >
>>> >> > They have absolutely no business knowing such an implementation detail.
>>> >>
>>> >> Hasn't that train already left the station with FS_XFLAG_DAX?
>>> >
>>> > No, that's an admin flag, not a runtime hint for applications. Just
>>> > because that flag is set on an inode, it does not mean that DAX is
>>> > actually in use - it will be ignored if the backing dev is not dax
>>> > capable.
>>>
>>> What's the point of an admin flag if an admin can't do cat /proc/<pid
>>> of interest>/smaps, or some other mechanism, to validate that the
>>> setting the admin cares about is in effect?
>>
>> Sorry, I don't follow - why would you be looking at mapping file
>> regions in /proc to determine if some file somewhere in a filesystem
>> has a specific flag set on it or not?
>>
>> FS_XFLAG_DAX is an inode attribute flag, not something you can
>> query or administrate through mmap:
>>
>> I.e.
>> # xfs_io -c "lsattr" -c "chattr +x" -c lsattr -c "chattr -x" -c "lsattr" foo
>>  --------------- foo
>>  --------------x foo
>>  --------------- foo
>> #
>>
>> What happens when that flag is set on an inode is determined by a
>> whole bunch of other things that are completely separate to the
>> management of the inode flag itself.
>
> Right, I understand that, but how does an admin audit those "bunch of
> other things" that actually gate whether DAX ends up being used in
> practice?  There's currently no way for userspace to observe that a
> file with FS_XFLAG_DAX actually results in a change in mmap behavior.

Let me put it another way, if we inadvertently break DAX causing it to
be disabled in scenarios when it should be enabled.  What is the
interface for the admin to check "I have the DAX inode flag set, but
the file this application expects to be mapped DAX is mapped with page
cache"?