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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 1 Dec 2020 11:44:32 -0600 From: Eric Sandeen <sandeen@...hat.com> To: "Darrick J. Wong" <darrick.wong@...cle.com> Cc: torvalds@...ux-foundation.org, Miklos Szeredi <mszeredi@...hat.com>, Ira Weiny <ira.weiny@...el.com>, David Howells <dhowells@...hat.com>, linux-fsdevel@...r.kernel.org, linux-man@...r.kernel.org, linux-kernel@...r.kernel.org, xfs <linux-xfs@...r.kernel.org>, linux-ext4@...r.kernel.org, Xiaoli Feng <xifeng@...hat.com> Subject: Re: [PATCH 1/2] uapi: fix statx attribute value overlap for DAX & MOUNT_ROOT On 12/1/20 11:32 AM, Darrick J. Wong wrote: > On Tue, Dec 01, 2020 at 10:57:11AM -0600, Eric Sandeen wrote: >> 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 <sandeen@...hat.com> >> --- >> 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. > > I don't really like using "DAX-enabled" to define "DAX attribute". How > about cribbing from the statx manpage? > > "Note that the DAX attribute indicates that the file is in the CPU > direct access state. It does not correspond to the per-inode flag that > some filesystems support." Sure. Consistency and specificity is good, I'll change that. >> */ >> #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 */ > > Why not use the next bit in the series (0x200000)? Did someone already > claim it in for-next? Since it didn't match the FS_IOC_SETFLAGS flag, I was trying to pick one that seemed unlikely to ever gain a corresponding statx flag, and since 0x00400000 is "reserved for ext4" it seemed like a decent choice. But 0x200000 corresponds to FS_EA_INODE_FL/EXT4_EA_INODE_FL which is ext4-specific as well, so sure, I'll change to that. Thanks, -Eric > --D > >> >> >> #endif /* _UAPI_LINUX_STAT_H */ >> -- >> 2.17.0 >> >
Powered by blists - more mailing lists