Re: UAPI value collision: STATX_ATTR_MOUNT_ROOT vs STATX_ATTR_DAX

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/25/20 10:50 AM, David Howells wrote:
> Hi Linus, Miklos, Ira,
> 
> It seems that two patches that got merged in the 5.8 merge window collided and
> no one noticed until now:
> 
> 80340fe3605c0 (Miklos Szeredi     2020-05-14 184) #define STATX_ATTR_MOUNT_ROOT		0x00002000 /* Root of a mount */
> ...
> 712b2698e4c02 (Ira Weiny          2020-04-30 186) #define STATX_ATTR_DAX			0x00002000 /* [I] File is DAX */
> 
> The question is, what do we do about it?  Renumber one or both of the
> constants?
> 
> David

Related to this, nothing sets STATX_ATTR_DAX into statx->attributes_mask,
anywhere in the kernel.

The flag is set into statx->attributes in vfs_getattr_nosec(), but that
does not know whether the particular filesystem under query supports dax
or not.

This is related to my other email about exactly what attributes_mask
means, so should STATX_ATTR_DAX be set in statx->attributes_mask only
in the filesystems that support dax?

(And should that be done only if CONFIG_DAX is turned on, etc?)

-Eric




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux