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  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, 1 Dec 2020 11:53:42 -0600
From:   Eric Sandeen <>
To:     "Darrick J. Wong" <>
        Miklos Szeredi <>,
        Ira Weiny <>,
        David Howells <>,,,, xfs <>,, Xiaoli Feng <>
Subject: Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to

On 12/1/20 11:39 AM, Darrick J. Wong wrote:
>> diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
>> index 1414ab79eacf..56deda7042fd 100644
>> --- a/fs/xfs/xfs_iops.c
>> +++ b/fs/xfs/xfs_iops.c
>> @@ -575,10 +575,13 @@ xfs_vn_getattr(
>>  		stat->attributes |= STATX_ATTR_APPEND;
>>  	if (ip->i_d.di_flags & XFS_DIFLAG_NODUMP)
>>  		stat->attributes |= STATX_ATTR_NODUMP;
>> +	if (IS_DAX(inode))
>> +		stat->attributes |= STATX_ATTR_DAX;
>>  	stat->attributes_mask |= (STATX_ATTR_IMMUTABLE |
>> +				  STATX_ATTR_DAX);
> TBH I preferred your previous iteration on this, which only set the DAX
> bit in the attributes_mask if the underlying storage was pmem and the
> blocksize was correct, etc. since it made it easier to distinguish
> between a filesystem where you /could/ have DAX (but it wasn't currently
> enabled) and a filesystem where it just isn't possible.
> That might be enough to satisfy any critics who want to be able to
> detect DAX support from an installer program.

(nb: that previous iteration wasn't in public, just something I talked to
Darrick about)

I'm sympathetic to that argument, but the exact details of what the mask means
in general, and for dax in particular, seems to be subject to ongoing debate.

I'd like to just set it with the simplest definition "the fileystem supports
the feature" for now, so that we aren't ever setting a feature that's omitted
from the mask, and refine the mask-setting for the dax flag in another
iteration if/when we reach agreement.


> --D

Powered by blists - more mailing lists