Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: UAPI value collision: STATX_ATTR_MOUNT_ROOT vs STATX_ATTR_DAX
To:     David Howells <dhowells@redhat.com>, torvalds@linux-foundation.org,
        Miklos Szeredi <mszeredi@redhat.com>,
        Ira Weiny <ira.weiny@intel.com>
Cc:     linux-fsdevel@vger.kernel.org, linux-man@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <1927370.1606323014@warthog.procyon.org.uk>
From:   Eric Sandeen <sandeen@redhat.com>
Message-ID: <fdf89cef-1350-e387-4d59-e6951255dbf0@redhat.com>
Date:   Wed, 25 Nov 2020 13:32:45 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <1927370.1606323014@warthog.procyon.org.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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