STATX_ATTR_MOUNT_ROOT and STATX_ATTR_DAX got merged with the same value,
so one of them needs fixing. Move STATX_ATTR_DAX.
While we're in here, clarify the value-matching scheme for some of the
attributes, and explain why the value for DAX does not match.
Signed-off-by: Eric Sandeen <[email protected]>
---
include/uapi/linux/stat.h | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
index 82cc58fe9368..9ad19eb9bbbf 100644
--- a/include/uapi/linux/stat.h
+++ b/include/uapi/linux/stat.h
@@ -171,9 +171,10 @@ struct statx {
* be of use to ordinary userspace programs such as GUIs or ls rather than
* specialised tools.
*
- * Note that the flags marked [I] correspond to generic FS_IOC_FLAGS
+ * Note that the flags marked [I] correspond to the FS_IOC_SETFLAGS flags
* semantically. Where possible, the numerical value is picked to correspond
- * also.
+ * also. Note that the DAX attribute indicates that the inode is currently
+ * DAX-enabled, not simply that the per-inode flag has been set.
*/
#define STATX_ATTR_COMPRESSED 0x00000004 /* [I] File is compressed by the fs */
#define STATX_ATTR_IMMUTABLE 0x00000010 /* [I] File is marked immutable */
@@ -183,7 +184,7 @@ struct statx {
#define STATX_ATTR_AUTOMOUNT 0x00001000 /* Dir: Automount trigger */
#define STATX_ATTR_MOUNT_ROOT 0x00002000 /* Root of a mount */
#define STATX_ATTR_VERITY 0x00100000 /* [I] Verity protected file */
-#define STATX_ATTR_DAX 0x00002000 /* [I] File is DAX */
+#define STATX_ATTR_DAX 0x00400000 /* File is currently DAX-enabled */
#endif /* _UAPI_LINUX_STAT_H */
--
2.17.0
On Wed, Dec 02, 2020 at 12:42:08PM -0800, Linus Torvalds wrote:
> On Tue, Dec 1, 2020 at 6:16 PM Ira Weiny <[email protected]> wrote:
> >
> > This will force a change to xfstests at a minimum. And I do know of users who
> > have been using this value. But I have gotten inquires about using the feature
> > so there are users out there.
>
> If it's only a few tests that fail, I wouldn't worry about it, and the
> tests should just be updated.
Done[1]
>
> But if there are real user concerns, we may need to have some kind of
> compat code. Because of the whole "no regressions" thing.
>
> What would the typical failure cases be in practice?
The failure will be a user not seeing their file operating in DAX mode when
they expect it to.
I discussed this with Dan Williams today. He and I agreed the flag is new
enough that we don't think users have any released code to the API just yet.
So I think we will be ok.
Also, after learning what the other flag was for I agree with Christoph that
the impact is going to be minimal since users are not typically operating on
the root inode.
So I think we are ok with just making the change and getting it into stable
quickly.
Thanks,
Ira
[1] https://lore.kernel.org/lkml/[email protected]/