[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fdf89cef-1350-e387-4d59-e6951255dbf0@redhat.com>
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
Powered by blists - more mailing lists