linux-kernel - Re: UAPI value collision: STATX_ATTR_MOUNT_ROOT vs STATX_ATTR

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:   Wed, 25 Nov 2020 13:32:45 -0600
From:   Eric Sandeen <sandeen@...hat.com>
To:     David Howells <dhowells@...hat.com>, torvalds@...ux-foundation.org,
        Miklos Szeredi <mszeredi@...hat.com>,
        Ira Weiny <ira.weiny@...el.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-man@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: UAPI value collision: STATX_ATTR_MOUNT_ROOT vs STATX_ATTR_DAX

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