* [RFC][PATCH 0/4] Enhanced file stat system call @ 2016-11-17 13:34 David Howells 2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells ` (7 more replies) 0 siblings, 8 replies; 52+ messages in thread From: David Howells @ 2016-11-17 13:34 UTC (permalink / raw) To: linux-fsdevel; +Cc: dhowells, linux-kernel Implement a new system call to provide enhanced file stats. The patches can be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat =========== DESCRIPTION =========== The first patch provides this new system call: long ret = statx(int dfd, const char *filename, unsigned atflag, unsigned mask, struct statx *buffer); This is an enhanced file stat function that provides a number of useful features, in summary: (1) More information: creation time, data version number and attributes. A subset of these is available through a number of filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS). (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of interest, and allow a network fs to approximate anything not of interest, without going to the server. (3) Heavyweight stat (AT_STATX_FORCE_SYNC): Force a network fs to flush buffers and go to the server, even if it thinks its cached attributes are up to date. (4) Allow the filesystem to indicate what it can/cannot provide: A filesystem can now say it doesn't support a standard stat feature if that isn't available. (5) Make the fields a consistent size on all arches, and make them large. (6) Can be extended by using more request flags and using up the padding space in the statx struct. Note that no lstat() equivalent is required as that can be implemented through statx() with atflag == 0. There is also no fstat() equivalent as that can be implemented through statx() with filename == NULL and the relevant fd passed as dfd. ======= TESTING ======= A test program is added into samples/statx/ by the first patch. David --- David Howells (4): statx: Add a system call to make enhanced file info available statx: Ext4: Return enhanced file attributes statx: NFS: Return enhanced file attributes statx: AFS: Return enhanced file attributes arch/x86/entry/syscalls/syscall_32.tbl | 1 arch/x86/entry/syscalls/syscall_64.tbl | 1 fs/afs/inode.c | 21 ++ fs/exportfs/expfs.c | 4 fs/ext4/ext4.h | 2 fs/ext4/file.c | 2 fs/ext4/inode.c | 38 ++++ fs/ext4/namei.c | 2 fs/ext4/symlink.c | 2 fs/nfs/inode.c | 41 ++++ fs/stat.c | 294 +++++++++++++++++++++++++++++--- include/linux/fs.h | 5 - include/linux/stat.h | 19 +- include/linux/syscalls.h | 3 include/uapi/linux/fcntl.h | 2 include/uapi/linux/stat.h | 124 +++++++++++++ samples/Kconfig | 5 + samples/Makefile | 3 samples/statx/Makefile | 10 + samples/statx/test-statx.c | 248 +++++++++++++++++++++++++++ 20 files changed, 771 insertions(+), 56 deletions(-) create mode 100644 samples/statx/Makefile create mode 100644 samples/statx/test-statx.c ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells @ 2016-11-17 13:35 ` David Howells 2016-11-17 18:39 ` Jeff Layton ` (5 more replies) 2016-11-17 13:35 ` [PATCH 2/4] statx: Ext4: Return enhanced file attributes David Howells ` (6 subsequent siblings) 7 siblings, 6 replies; 52+ messages in thread From: David Howells @ 2016-11-17 13:35 UTC (permalink / raw) To: linux-fsdevel; +Cc: dhowells, linux-kernel Add a system call to make extended file information available, including file creation, data version and some attribute flags where available through the underlying filesystem. ======== OVERVIEW ======== The idea was initially proposed as a set of xattrs that could be retrieved with getxattr(), but the general preferance proved to be for a new syscall with an extended stat structure. This has a number of uses: (1) Better support for the y2038 problem [Arnd Bergmann]. (2) Creation time: The SMB protocol carries the creation time, which could be exported by Samba, which will in turn help CIFS make use of FS-Cache as that can be used for coherency data. This is also specified in NFSv4 as a recommended attribute and could be exported by NFSD [Steve French]. (3) Lightweight stat: Ask for just those details of interest, and allow a netfs (such as NFS) to approximate anything not of interest, possibly without going to the server [Trond Myklebust, Ulrich Drepper, Andreas Dilger]. (4) Heavyweight stat: Force a netfs to go to the server, even if it thinks its cached attributes are up to date [Trond Myklebust]. (5) Data version number: Could be used by userspace NFS servers [Aneesh Kumar]. Can also be used to modify fill_post_wcc() in NFSD which retrieves i_version directly, but has just called vfs_getattr(). It could get it from the kstat struct if it used vfs_xgetattr() instead. (6) BSD stat compatibility: Including more fields from the BSD stat such as creation time (st_btime) and inode generation number (st_gen) [Jeremy Allison, Bernd Schubert]. (7) Inode generation number: Useful for FUSE and userspace NFS servers [Bernd Schubert]. This was asked for but later deemed unnecessary with the open-by-handle capability available (8) Extra coherency data may be useful in making backups [Andreas Dilger]. (9) Allow the filesystem to indicate what it can/cannot provide: A filesystem can now say it doesn't support a standard stat feature if that isn't available, so if, for instance, inode numbers or UIDs don't exist or are fabricated locally... (10) Make the fields a consistent size on all arches and make them large. (11) Store a 16-byte volume ID in the superblock that can be returned in struct xstat [Steve French]. (12) Include granularity fields in the time data to indicate the granularity of each of the times (NFSv4 time_delta) [Steve French]. (13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. Note that the Linux IOC flags are a mess and filesystems such as Ext4 define flags that aren't in linux/fs.h, so translation in the kernel may be a necessity (or, possibly, we provide the filesystem type too). (14) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer, Michael Kerrisk]. (15) Spare space, request flags and information flags are provided for future expansion. Note that not all of the above are implemented here. =============== NEW SYSTEM CALL =============== The new system call is: int ret = statx(int dfd, const char *filename, unsigned int flags, unsigned int mask, struct statx *buffer); The dfd, filename and flags parameters indicate the file to query. There is no equivalent of lstat() as that can be emulated with statx() by passing AT_SYMLINK_NOFOLLOW in flags. There is also no equivalent of fstat() as that can be emulated by passing a NULL filename to statx() with the fd of interest in dfd. AT_STATX_FORCE_SYNC can be set in flags. This will require a network filesystem to synchronise its attributes with the server. AT_STATX_DONT_SYNC can be set in flags. This will suppress synchronisation with the server in a network filesystem. The resulting values should be considered approximate. If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for stat() on that filesystem. mask is a bitmask indicating the fields in struct statx that are of interest to the caller. The user should set this to STATX_BASIC_STATS to get the basic set returned by stat(). It should be note that asking for more information may entail more I/O operations. buffer points to the destination for the data. This must be 256 bytes in size. ====================== MAIN ATTRIBUTES RECORD ====================== The following structures are defined in which to return the main attribute set: struct statx { __u32 stx_mask; __u32 stx_blksize; __u64 stx_attributes; __u32 stx_nlink; __u32 stx_uid; __u32 stx_gid; __u16 stx_mode; __u16 __spare0[1]; __u64 stx_ino; __u64 stx_size; __u64 stx_blocks; __u64 stx_version; __s64 stx_atime; __s64 stx_btime; __s64 stx_ctime; __s64 stx_mtime; __s32 stx_atime_ns; __s32 stx_btime_ns; __s32 stx_ctime_ns; __s32 stx_mtime_ns; __u32 stx_rdev_major; __u32 stx_rdev_minor; __u32 stx_dev_major; __u32 stx_dev_minor; __u64 __spare1[16]; }; The defined bits in request_mask and stx_mask are: STATX_TYPE Want/got stx_mode & S_IFMT STATX_MODE Want/got stx_mode & ~S_IFMT STATX_NLINK Want/got stx_nlink STATX_UID Want/got stx_uid STATX_GID Want/got stx_gid STATX_ATIME Want/got stx_atime{,_ns} STATX_MTIME Want/got stx_mtime{,_ns} STATX_CTIME Want/got stx_ctime{,_ns} STATX_INO Want/got stx_ino STATX_SIZE Want/got stx_size STATX_BLOCKS Want/got stx_blocks STATX_BASIC_STATS [The stuff in the normal stat struct] STATX_BTIME Want/got stx_btime{,_ns} STATX_VERSION Want/got stx_version STATX_ALL [All currently available stuff] stx_btime is the file creation time; stx_version is the data version number (i_version); stx_mask is a bitmask indicating the data provided; and __spares*[] are where as-yet undefined fields can be placed. Time fields are split into separate seconds and nanoseconds fields to make packing easier and the granularities can be queried with the filesystem info system call. Note that times will be negative if before 1970; in such a case, the nanosecond fields will also be negative if not zero. The bits defined in the stx_attributes field convey information about a file, how it is accessed, where it is and what it does. The following attributes map to FS_*_FL flags and are the same numerical value: STATX_ATTR_COMPRESSED File is compressed by the fs STATX_ATTR_IMMUTABLE File is marked immutable STATX_ATTR_APPEND File is append-only STATX_ATTR_NODUMP File is not to be dumped STATX_ATTR_ENCRYPTED File requires key to decrypt in fs The supported flags are listed by: STATX_ATTR_FS_IOC_FLAGS [Are any other IOC flags of sufficient general interest to be exposed through this interface?] New flags include: STATX_ATTR_NONUNIX_OWNERSHIP File doesn't have Unixy ownership STATX_ATTR_HAS_ACL File has an ACL STATX_ATTR_KERNEL_API File is kernel API (eg: procfs/sysfs) STATX_ATTR_REMOTE File is remote and needs network STATX_ATTR_FABRICATED File was made up by fs STATX_ATTR_AUTOMOUNT Object is an automount trigger STATX_ATTR_UNLISTED_DENTS Dir: Lookup may find files getdents doesn't These are for the use of GUI tools that might want to mark files specially, depending on what they are. Fields in struct statx come in a number of classes: (0) stx_dev_*, stx_blksize. These are local system information and are always available. (1) stx_mode, stx_nlinks, stx_uid, stx_gid, stx_[amc]time*, stx_ino, stx_size, stx_blocks. These will be returned whether the caller asks for them or not. The corresponding bits in stx_mask will be set to indicate whether they actually have valid values. If the caller didn't ask for them, then they may be approximated. For example, NFS won't waste any time updating them from the server, unless as a byproduct of updating something requested. If the values don't actually exist for the underlying object (such as UID or GID on a DOS file), then the bit won't be set in the stx_mask, even if the caller asked for the value. In such a case, the returned value will be a fabrication. Note that there are instances where the type might not be valid, for instance Windows reparse points. (2) stx_rdev_*. This will be set only if stx_mode indicates we're looking at a blockdev or a chardev, otherwise will be 0. (3) stx_btime*, stx_version. Similar to (1), except these will be set to 0 if they don't exist. ======= TESTING ======= The following test program can be used to test the statx system call: samples/statx/test-statx.c Just compile and run, passing it paths to the files you want to examine. The file is built automatically if CONFIG_SAMPLES is enabled. Here's some example output. Firstly, an NFS directory that crosses to another FSID. Note that the FABRICATED and AUTOMOUNT info flags are set. The former because the directory is invented locally as we don't see the underlying dir on the server, the latter because transiting this directory will cause d_automount to be invoked by the VFS. [root@andromeda tmp]# ./samples/statx/test-statx -A /warthog/data statx(/warthog/data) = 0 results=17ff Size: 4096 Blocks: 8 IO Block: 1048576 directory Device: 00:26 Inode: 1703937 Links: 124 Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041 Access: 2016-11-10 15:52:11.219935864+0000 Modify: 2016-11-10 08:07:32.482314928+0000 Change: 2016-11-10 08:07:32.482314928+0000 Data version: 58242ac41cbf8ab0h Attributes: 000000000000e000 (-------- -------- -------- -------- -------- -------- mfr----- --------) IO-blocksize: blksize=1048576 Secondly, the result of automounting on that directory. [root@andromeda tmp]# ./samples/statx/test-statx /warthog/data statx(/warthog/data) = 0 results=17ff Size: 4096 Blocks: 8 IO Block: 1048576 directory Device: 00:27 Inode: 2 Links: 124 Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041 Access: 2016-11-10 15:52:11.219935864+0000 Modify: 2016-11-10 08:07:32.482314928+0000 Change: 2016-11-10 08:07:32.482314928+0000 Data version: 58242ac41cbf8ab0h Attributes: 0000000000002000 (-------- -------- -------- -------- -------- -------- --r----- --------) IO-blocksize: blksize=1048576 Signed-off-by: David Howells <dhowells@redhat.com> --- arch/x86/entry/syscalls/syscall_32.tbl | 1 arch/x86/entry/syscalls/syscall_64.tbl | 1 fs/exportfs/expfs.c | 4 fs/stat.c | 294 +++++++++++++++++++++++++++++--- include/linux/fs.h | 5 - include/linux/stat.h | 19 +- include/linux/syscalls.h | 3 include/uapi/linux/fcntl.h | 2 include/uapi/linux/stat.h | 124 +++++++++++++ samples/Kconfig | 5 + samples/Makefile | 3 samples/statx/Makefile | 10 + samples/statx/test-statx.c | 248 +++++++++++++++++++++++++++ 13 files changed, 679 insertions(+), 40 deletions(-) create mode 100644 samples/statx/Makefile create mode 100644 samples/statx/test-statx.c diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl index 2b3618542544..9ba050fe47f3 100644 --- a/arch/x86/entry/syscalls/syscall_32.tbl +++ b/arch/x86/entry/syscalls/syscall_32.tbl @@ -389,3 +389,4 @@ 380 i386 pkey_mprotect sys_pkey_mprotect 381 i386 pkey_alloc sys_pkey_alloc 382 i386 pkey_free sys_pkey_free +383 i386 statx sys_statx diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl index e93ef0b38db8..5aef183e2f85 100644 --- a/arch/x86/entry/syscalls/syscall_64.tbl +++ b/arch/x86/entry/syscalls/syscall_64.tbl @@ -338,6 +338,7 @@ 329 common pkey_mprotect sys_pkey_mprotect 330 common pkey_alloc sys_pkey_alloc 331 common pkey_free sys_pkey_free +332 common statx sys_statx # # x32-specific system call numbers start at 512 to avoid cache impact diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c index a4b531be9168..2acc31751248 100644 --- a/fs/exportfs/expfs.c +++ b/fs/exportfs/expfs.c @@ -299,7 +299,9 @@ static int get_name(const struct path *path, char *name, struct dentry *child) * filesystem supports 64-bit inode numbers. So we need to * actually call ->getattr, not just read i_ino: */ - error = vfs_getattr_nosec(&child_path, &stat); + stat.query_flags = 0; + stat.request_mask = STATX_BASIC_STATS; + error = vfs_xgetattr_nosec(&child_path, &stat); if (error) return error; buffer.ino = stat.ino; diff --git a/fs/stat.c b/fs/stat.c index bc045c7994e1..78c0a5086038 100644 --- a/fs/stat.c +++ b/fs/stat.c @@ -18,6 +18,15 @@ #include <asm/uaccess.h> #include <asm/unistd.h> +/** + * generic_fillattr - Fill in the basic attributes from the inode struct + * @inode: Inode to use as the source + * @stat: Where to fill in the attributes + * + * Fill in the basic attributes in the kstat structure from data that's to be + * found on the VFS inode structure. This is the default if no getattr inode + * operation is supplied. + */ void generic_fillattr(struct inode *inode, struct kstat *stat) { stat->dev = inode->i_sb->s_dev; @@ -27,87 +36,189 @@ void generic_fillattr(struct inode *inode, struct kstat *stat) stat->uid = inode->i_uid; stat->gid = inode->i_gid; stat->rdev = inode->i_rdev; - stat->size = i_size_read(inode); - stat->atime = inode->i_atime; stat->mtime = inode->i_mtime; stat->ctime = inode->i_ctime; - stat->blksize = (1 << inode->i_blkbits); + stat->size = i_size_read(inode); stat->blocks = inode->i_blocks; -} + stat->blksize = 1 << inode->i_blkbits; + stat->result_mask |= STATX_BASIC_STATS; + if (IS_NOATIME(inode)) + stat->result_mask &= ~STATX_ATIME; + else + stat->atime = inode->i_atime; + + if (IS_AUTOMOUNT(inode)) + stat->attributes |= STATX_ATTR_AUTOMOUNT; +} EXPORT_SYMBOL(generic_fillattr); /** - * vfs_getattr_nosec - getattr without security checks + * vfs_xgetattr_nosec - getattr without security checks * @path: file to get attributes from * @stat: structure to return attributes in * * Get attributes without calling security_inode_getattr. * - * Currently the only caller other than vfs_getattr is internal to the - * filehandle lookup code, which uses only the inode number and returns - * no attributes to any user. Any other code probably wants - * vfs_getattr. + * Currently the only caller other than vfs_xgetattr is internal to the + * filehandle lookup code, which uses only the inode number and returns no + * attributes to any user. Any other code probably wants vfs_xgetattr. + * + * The caller must set stat->request_mask to indicate what they want and + * stat->query_flags to indicate whether the server should be queried. */ -int vfs_getattr_nosec(struct path *path, struct kstat *stat) +int vfs_xgetattr_nosec(struct path *path, struct kstat *stat) { struct inode *inode = d_backing_inode(path->dentry); + stat->query_flags &= ~KSTAT_QUERY_FLAGS; + + stat->result_mask = 0; + stat->attributes = 0; if (inode->i_op->getattr) return inode->i_op->getattr(path->mnt, path->dentry, stat); generic_fillattr(inode, stat); return 0; } +EXPORT_SYMBOL(vfs_xgetattr_nosec); -EXPORT_SYMBOL(vfs_getattr_nosec); - -int vfs_getattr(struct path *path, struct kstat *stat) +/* + * vfs_xgetattr - Get the enhanced basic attributes of a file + * @path: The file of interest + * @stat: Where to return the statistics + * + * Ask the filesystem for a file's attributes. The caller must have preset + * stat->request_mask and stat->query_flags to indicate what they want. + * + * If the file is remote, the filesystem can be forced to update the attributes + * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags or can + * suppress the update by passing AT_NO_ATTR_SYNC. + * + * Bits must have been set in stat->request_mask to indicate which attributes + * the caller wants retrieving. Any such attribute not requested may be + * returned anyway, but the value may be approximate, and, if remote, may not + * have been synchronised with the server. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_xgetattr(struct path *path, struct kstat *stat) { int retval; retval = security_inode_getattr(path); if (retval) return retval; - return vfs_getattr_nosec(path, stat); + return vfs_xgetattr_nosec(path, stat); } +EXPORT_SYMBOL(vfs_xgetattr); +/** + * vfs_getattr - Get the basic attributes of a file + * @path: The file of interest + * @stat: Where to return the statistics + * + * Ask the filesystem for a file's attributes. If remote, the filesystem isn't + * forced to update its files from the backing store. Only the basic set of + * attributes will be retrieved; anyone wanting more must use vfs_xgetattr(), + * as must anyone who wants to force attributes to be sync'd with the server. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_getattr(struct path *path, struct kstat *stat) +{ + stat->query_flags = 0; + stat->request_mask = STATX_BASIC_STATS; + return vfs_xgetattr(path, stat); +} EXPORT_SYMBOL(vfs_getattr); -int vfs_fstat(unsigned int fd, struct kstat *stat) +/** + * vfs_fstatx - Get the enhanced basic attributes by file descriptor + * @fd: The file descriptor referring to the file of interest + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_xgetattr(). The main difference is + * that it uses a file descriptor to determine the file location. + * + * The caller must have preset stat->query_flags and stat->request_mask as for + * vfs_xgetattr(). + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_fstatx(unsigned int fd, struct kstat *stat) { struct fd f = fdget_raw(fd); int error = -EBADF; if (f.file) { - error = vfs_getattr(&f.file->f_path, stat); + error = vfs_xgetattr(&f.file->f_path, stat); fdput(f); } return error; } +EXPORT_SYMBOL(vfs_fstatx); + +/** + * vfs_fstat - Get basic attributes by file descriptor + * @fd: The file descriptor referring to the file of interest + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_getattr(). The main difference is + * that it uses a file descriptor to determine the file location. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_fstat(unsigned int fd, struct kstat *stat) +{ + stat->query_flags = 0; + stat->request_mask = STATX_BASIC_STATS; + return vfs_fstatx(fd, stat); +} EXPORT_SYMBOL(vfs_fstat); -int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, - int flag) +/** + * vfs_statx - Get basic and extra attributes by filename + * @dfd: A file descriptor representing the base dir for a relative filename + * @filename: The name of the file of interest + * @flags: Flags to control the query + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_xgetattr(). The main difference is + * that it uses a filename and base directory to determine the file location. + * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a + * symlink at the given name from being referenced. + * + * The caller must have preset stat->request_mask as for vfs_xgetattr(). The + * flags are also used to load up stat->query_flags. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_statx(int dfd, const char __user *filename, int flags, + struct kstat *stat) { struct path path; int error = -EINVAL; - unsigned int lookup_flags = 0; + unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT; - if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | - AT_EMPTY_PATH)) != 0) - goto out; + if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | + AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0) + return -EINVAL; - if (!(flag & AT_SYMLINK_NOFOLLOW)) - lookup_flags |= LOOKUP_FOLLOW; - if (flag & AT_EMPTY_PATH) + if (flags & AT_SYMLINK_NOFOLLOW) + lookup_flags &= ~LOOKUP_FOLLOW; + if (flags & AT_NO_AUTOMOUNT) + lookup_flags &= ~LOOKUP_AUTOMOUNT; + if (flags & AT_EMPTY_PATH) lookup_flags |= LOOKUP_EMPTY; + stat->query_flags = flags; + retry: error = user_path_at(dfd, filename, lookup_flags, &path); if (error) goto out; - error = vfs_getattr(&path, stat); + error = vfs_xgetattr(&path, stat); path_put(&path); if (retry_estale(error, lookup_flags)) { lookup_flags |= LOOKUP_REVAL; @@ -116,17 +227,65 @@ int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, out: return error; } +EXPORT_SYMBOL(vfs_statx); + +/** + * vfs_fstatat - Get basic attributes by filename + * @dfd: A file descriptor representing the base dir for a relative filename + * @filename: The name of the file of interest + * @flags: Flags to control the query + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_statx(). The difference is that it + * preselects basic stats only. The flags are used to load up + * stat->query_flags in addition to indicating symlink handling during path + * resolution. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, + int flags) +{ + stat->request_mask = STATX_BASIC_STATS; + return vfs_statx(dfd, filename, flags, stat); +} EXPORT_SYMBOL(vfs_fstatat); -int vfs_stat(const char __user *name, struct kstat *stat) +/** + * vfs_stat - Get basic attributes by filename + * @filename: The name of the file of interest + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_statx(). The difference is that it + * preselects basic stats only, terminal symlinks are followed regardless and a + * remote filesystem can't be forced to query the server. If such is desired, + * vfs_statx() should be used instead. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_stat(const char __user *filename, struct kstat *stat) { - return vfs_fstatat(AT_FDCWD, name, stat, 0); + stat->request_mask = STATX_BASIC_STATS; + return vfs_statx(AT_FDCWD, filename, 0, stat); } EXPORT_SYMBOL(vfs_stat); +/** + * vfs_lstat - Get basic attrs by filename, without following terminal symlink + * @filename: The name of the file of interest + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_statx(). The difference is that it + * preselects basic stats only, terminal symlinks are note followed regardless + * and a remote filesystem can't be forced to query the server. If such is + * desired, vfs_statx() should be used instead. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ int vfs_lstat(const char __user *name, struct kstat *stat) { - return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW); + stat->request_mask = STATX_BASIC_STATS; + return vfs_statx(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat); } EXPORT_SYMBOL(vfs_lstat); @@ -141,7 +300,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta { static int warncount = 5; struct __old_kernel_stat tmp; - + if (warncount > 0) { warncount--; printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n", @@ -166,7 +325,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta #if BITS_PER_LONG == 32 if (stat->size > MAX_NON_LFS) return -EOVERFLOW; -#endif +#endif tmp.st_size = stat->size; tmp.st_atime = stat->atime.tv_sec; tmp.st_mtime = stat->mtime.tv_sec; @@ -443,6 +602,79 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename, } #endif /* __ARCH_WANT_STAT64 || __ARCH_WANT_COMPAT_STAT64 */ +/* + * Set the statx results. + */ +static long statx_set_result(struct kstat *stat, struct statx __user *buffer) +{ + uid_t uid = from_kuid_munged(current_user_ns(), stat->uid); + gid_t gid = from_kgid_munged(current_user_ns(), stat->gid); + +#define __put_timestamp(kts, uts) ( \ + __put_user(kts.tv_sec, uts##_s ) || \ + __put_user(kts.tv_nsec, uts##_ns )) + + if (__put_user(stat->result_mask, &buffer->stx_mask ) || + __put_user(stat->mode, &buffer->stx_mode ) || + __clear_user(&buffer->__spare0, sizeof(buffer->__spare0)) || + __put_user(stat->nlink, &buffer->stx_nlink ) || + __put_user(uid, &buffer->stx_uid ) || + __put_user(gid, &buffer->stx_gid ) || + __put_user(stat->attributes, &buffer->stx_attributes ) || + __put_user(stat->blksize, &buffer->stx_blksize ) || + __put_user(MAJOR(stat->rdev), &buffer->stx_rdev_major ) || + __put_user(MINOR(stat->rdev), &buffer->stx_rdev_minor ) || + __put_user(MAJOR(stat->dev), &buffer->stx_dev_major ) || + __put_user(MINOR(stat->dev), &buffer->stx_dev_minor ) || + __put_timestamp(stat->atime, &buffer->stx_atime ) || + __put_timestamp(stat->btime, &buffer->stx_btime ) || + __put_timestamp(stat->ctime, &buffer->stx_ctime ) || + __put_timestamp(stat->mtime, &buffer->stx_mtime ) || + __put_user(stat->ino, &buffer->stx_ino ) || + __put_user(stat->size, &buffer->stx_size ) || + __put_user(stat->blocks, &buffer->stx_blocks ) || + __put_user(stat->version, &buffer->stx_version ) || + __clear_user(&buffer->__spare1, sizeof(buffer->__spare1))) + return -EFAULT; + + return 0; +} + +/** + * sys_statx - System call to get enhanced stats + * @dfd: Base directory to pathwalk from *or* fd to stat. + * @filename: File to stat *or* NULL. + * @flags: AT_* flags to control pathwalk. + * @mask: Parts of statx struct actually required. + * @buffer: Result buffer. + * + * Note that if filename is NULL, then it does the equivalent of fstat() using + * dfd to indicate the file of interest. + */ +SYSCALL_DEFINE5(statx, + int, dfd, const char __user *, filename, unsigned, flags, + unsigned int, mask, + struct statx __user *, buffer) +{ + struct kstat stat; + int error; + + if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer))) + return -EFAULT; + + memset(&stat, 0, sizeof(stat)); + stat.query_flags = flags; + stat.request_mask = mask & STATX_ALL; + + if (filename) + error = vfs_statx(dfd, filename, flags, &stat); + else + error = vfs_fstatx(dfd, &stat); + if (error) + return error; + return statx_set_result(&stat, buffer); +} + /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */ void __inode_add_bytes(struct inode *inode, loff_t bytes) { diff --git a/include/linux/fs.h b/include/linux/fs.h index 16d2b6e874d6..f153199566b4 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -2916,8 +2916,9 @@ extern const struct inode_operations page_symlink_inode_operations; extern void kfree_link(void *); extern int generic_readlink(struct dentry *, char __user *, int); extern void generic_fillattr(struct inode *, struct kstat *); -int vfs_getattr_nosec(struct path *path, struct kstat *stat); +extern int vfs_xgetattr_nosec(struct path *path, struct kstat *stat); extern int vfs_getattr(struct path *, struct kstat *); +extern int vfs_xgetattr(struct path *, struct kstat *); void __inode_add_bytes(struct inode *inode, loff_t bytes); void inode_add_bytes(struct inode *inode, loff_t bytes); void __inode_sub_bytes(struct inode *inode, loff_t bytes); @@ -2935,6 +2936,8 @@ extern int vfs_lstat(const char __user *, struct kstat *); extern int vfs_fstat(unsigned int, struct kstat *); extern int vfs_fstatat(int , const char __user *, struct kstat *, int); extern const char *vfs_get_link(struct dentry *, struct delayed_call *); +extern int vfs_xstat(int, const char __user *, int, struct kstat *); +extern int vfs_xfstat(unsigned int, struct kstat *); extern int __generic_block_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo, diff --git a/include/linux/stat.h b/include/linux/stat.h index 075cb0c7eb2a..cf25bb5cf754 100644 --- a/include/linux/stat.h +++ b/include/linux/stat.h @@ -19,19 +19,26 @@ #include <linux/uidgid.h> struct kstat { - u64 ino; - dev_t dev; + u32 query_flags; /* Operational flags */ +#define KSTAT_QUERY_FLAGS (AT_STATX_FORCE_SYNC | AT_STATX_DONT_SYNC) + u32 request_mask; /* What fields the user asked for */ + u32 result_mask; /* What fields the user got */ umode_t mode; unsigned int nlink; + uint32_t blksize; /* Preferred I/O size */ + u64 attributes; + u64 ino; + dev_t dev; + dev_t rdev; kuid_t uid; kgid_t gid; - dev_t rdev; loff_t size; - struct timespec atime; + struct timespec atime; struct timespec mtime; struct timespec ctime; - unsigned long blksize; - unsigned long long blocks; + struct timespec btime; /* File creation time */ + u64 blocks; + u64 version; /* Data version */ }; #endif diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index 91a740f6b884..980c3c9b06f8 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -48,6 +48,7 @@ struct stat; struct stat64; struct statfs; struct statfs64; +struct statx; struct __sysctl_args; struct sysinfo; struct timespec; @@ -902,5 +903,7 @@ asmlinkage long sys_pkey_mprotect(unsigned long start, size_t len, unsigned long prot, int pkey); asmlinkage long sys_pkey_alloc(unsigned long flags, unsigned long init_val); asmlinkage long sys_pkey_free(int pkey); +asmlinkage long sys_statx(int dfd, const char __user *path, unsigned flags, + unsigned mask, struct statx __user *buffer); #endif diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h index beed138bd359..c49cb6edaafa 100644 --- a/include/uapi/linux/fcntl.h +++ b/include/uapi/linux/fcntl.h @@ -62,6 +62,8 @@ #define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */ #define AT_NO_AUTOMOUNT 0x800 /* Suppress terminal automount traversal */ #define AT_EMPTY_PATH 0x1000 /* Allow empty relative pathname */ +#define AT_STATX_FORCE_SYNC 0x2000 /* Force the attributes to be sync'd with the server */ +#define AT_STATX_DONT_SYNC 0x4000 /* Don't sync attributes with the server */ #endif /* _UAPI_LINUX_FCNTL_H */ diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h index 7fec7e36d921..32ea14c1c960 100644 --- a/include/uapi/linux/stat.h +++ b/include/uapi/linux/stat.h @@ -1,6 +1,7 @@ #ifndef _UAPI_LINUX_STAT_H #define _UAPI_LINUX_STAT_H +#include <linux/types.h> #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) @@ -41,5 +42,128 @@ #endif +/* + * Structures for the extended file attribute retrieval system call + * (statx()). + * + * The caller passes a mask of what they're specifically interested in as a + * parameter to statx(). What statx() actually got will be indicated in + * st_mask upon return. + * + * For each bit in the mask argument: + * + * - if the datum is not supported: + * + * - the bit will be cleared, and + * + * - the datum will be set to an appropriate fabricated value if one is + * available (eg. CIFS can take a default uid and gid), otherwise + * + * - the field will be cleared; + * + * - otherwise, if explicitly requested: + * + * - the datum will be synchronised to the server if AT_STATX_FORCE_SYNC is + * set or if the datum is considered out of date, and + * + * - the field will be filled in and the bit will be set; + * + * - otherwise, if not requested, but available in approximate form without any + * effort, it will be filled in anyway, and the bit will be set upon return + * (it might not be up to date, however, and no attempt will be made to + * synchronise the internal state first); + * + * - otherwise the field and the bit will be cleared before returning. + * + * Items in STATX_BASIC_STATS may be marked unavailable on return, but they + * will have values installed for compatibility purposes so that stat() and + * co. can be emulated in userspace. + */ +struct statx { + /* 0x00 */ + __u32 stx_mask; /* What results were written [uncond] */ + __u32 stx_blksize; /* Preferred general I/O size [uncond] */ + __u64 stx_attributes; /* Flags conveying information about the file [uncond] */ + /* 0x10 */ + __u32 stx_nlink; /* Number of hard links */ + __u32 stx_uid; /* User ID of owner */ + __u32 stx_gid; /* Group ID of owner */ + __u16 stx_mode; /* File mode */ + __u16 __spare0[1]; + /* 0x20 */ + __u64 stx_ino; /* Inode number */ + __u64 stx_size; /* File size */ + __u64 stx_blocks; /* Number of 512-byte blocks allocated */ + __u64 stx_version; /* Data version number */ + /* 0x40 */ + __s64 stx_atime_s; /* Last access time */ + __s64 stx_btime_s; /* File creation time */ + __s64 stx_ctime_s; /* Last attribute change time */ + __s64 stx_mtime_s; /* Last data modification time */ + /* 0x60 */ + __s32 stx_atime_ns; /* Last access time (ns part) */ + __s32 stx_btime_ns; /* File creation time (ns part) */ + __s32 stx_ctime_ns; /* Last attribute change time (ns part) */ + __s32 stx_mtime_ns; /* Last data modification time (ns part) */ + /* 0x70 */ + __u32 stx_rdev_major; /* Device ID of special file [if bdev/cdev] */ + __u32 stx_rdev_minor; + __u32 stx_dev_major; /* ID of device containing file [uncond] */ + __u32 stx_dev_minor; + /* 0x80 */ + __u64 __spare1[16]; /* Spare space for future expansion */ + /* 0x100 */ +}; + +/* + * Flags to be stx_mask + * + * Query request/result mask for statx() and struct statx::stx_mask. + * + * These bits should be set in the mask argument of statx() to request + * particular items when calling statx(). + */ +#define STATX_TYPE 0x00000001U /* Want/got stx_mode & S_IFMT */ +#define STATX_MODE 0x00000002U /* Want/got stx_mode & ~S_IFMT */ +#define STATX_NLINK 0x00000004U /* Want/got stx_nlink */ +#define STATX_UID 0x00000008U /* Want/got stx_uid */ +#define STATX_GID 0x00000010U /* Want/got stx_gid */ +#define STATX_ATIME 0x00000020U /* Want/got stx_atime */ +#define STATX_MTIME 0x00000040U /* Want/got stx_mtime */ +#define STATX_CTIME 0x00000080U /* Want/got stx_ctime */ +#define STATX_INO 0x00000100U /* Want/got stx_ino */ +#define STATX_SIZE 0x00000200U /* Want/got stx_size */ +#define STATX_BLOCKS 0x00000400U /* Want/got stx_blocks */ +#define STATX_BASIC_STATS 0x000007ffU /* The stuff in the normal stat struct */ +#define STATX_BTIME 0x00000800U /* Want/got stx_btime */ +#define STATX_VERSION 0x00001000U /* Want/got stx_version */ +#define STATX_ALL 0x00001fffU /* All currently supported flags */ + +/* + * Attributes to be found in stx_attributes + * + * These give information about the features or the state of a file that might + * 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 + * semantically. Where possible, the numerical value is picked to correspond + * also. + */ +#define STATX_ATTR_COMPRESSED 0x00000004 /* [I] File is compressed by the fs */ +#define STATX_ATTR_IMMUTABLE 0x00000010 /* [I] File is marked immutable */ +#define STATX_ATTR_APPEND 0x00000020 /* [I] File is append-only */ +#define STATX_ATTR_NODUMP 0x00000040 /* [I] File is not to be dumped */ +#define STATX_ATTR_NONUNIX_OWNERSHIP 0x00000100 /* File has non-Unix ownership details */ +#define STATX_ATTR_HAS_ACL 0x00000200 /* File has an ACL */ +#define STATX_ATTR_ENCRYPTED 0x00000800 /* [I] File requires key to decrypt in fs */ +#define STATX_ATTR_FS_IOC_FLAGS 0x00000874 /* Attrs corresponding to FS_*_FL flags */ + +#define STATX_ATTR_KERNEL_API 0x00001000 /* File is kernel API (eg: procfs/sysfs) */ +#define STATX_ATTR_REMOTE 0x00002000 /* File is remote and needs network */ +#define STATX_ATTR_FABRICATED 0x00004000 /* File was made up by fs and is transient */ +#define STATX_ATTR_AUTOMOUNT 0x00008000 /* Dir: Automount trigger */ +#define STATX_ATTR_UNLISTED_DENTS 0x00010000 /* Dir: Lookup may find files getdents doesn't */ + #endif /* _UAPI_LINUX_STAT_H */ diff --git a/samples/Kconfig b/samples/Kconfig index a6d2a43bbf2e..94a7488f14ae 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -105,4 +105,9 @@ config SAMPLE_BLACKFIN_GPTIMERS help Build samples of blackfin gptimers sample module. +config SAMPLE_STATX + bool "Build example extended-stat using code" + help + Build example userspace program to use the new extended-stat syscall. + endif # SAMPLES diff --git a/samples/Makefile b/samples/Makefile index e17d66d77f09..8eeb15e13413 100644 --- a/samples/Makefile +++ b/samples/Makefile @@ -2,4 +2,5 @@ obj-$(CONFIG_SAMPLES) += kobject/ kprobes/ trace_events/ livepatch/ \ hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ \ - configfs/ connector/ v4l/ trace_printk/ blackfin/ + configfs/ connector/ v4l/ trace_printk/ blackfin/ \ + statx/ diff --git a/samples/statx/Makefile b/samples/statx/Makefile new file mode 100644 index 000000000000..1f80a3d8cf45 --- /dev/null +++ b/samples/statx/Makefile @@ -0,0 +1,10 @@ +# kbuild trick to avoid linker error. Can be omitted if a module is built. +obj- := dummy.o + +# List of programs to build +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx + +# Tell kbuild to always build the programs +always := $(hostprogs-y) + +HOSTCFLAGS_test-statx.o += -I$(objtree)/usr/include diff --git a/samples/statx/test-statx.c b/samples/statx/test-statx.c new file mode 100644 index 000000000000..2419b33fc15d --- /dev/null +++ b/samples/statx/test-statx.c @@ -0,0 +1,248 @@ +/* Test the statx() system call + * + * Copyright (C) 2015 Red Hat, Inc. All Rights Reserved. + * Written by David Howells (dhowells@redhat.com) + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public Licence + * as published by the Free Software Foundation; either version + * 2 of the Licence, or (at your option) any later version. + */ + +#define _GNU_SOURCE +#define _ATFILE_SOURCE +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <ctype.h> +#include <errno.h> +#include <time.h> +#include <sys/syscall.h> +#include <sys/types.h> +#include <linux/stat.h> +#include <linux/fcntl.h> +#include <sys/stat.h> + +#define AT_STATX_FORCE_SYNC 0x2000 +#define AT_STATX_DONT_SYNC 0x4000 + +static __attribute__((unused)) +ssize_t statx(int dfd, const char *filename, unsigned flags, + unsigned int mask, struct statx *buffer) +{ + return syscall(__NR_statx, dfd, filename, flags, mask, buffer); +} + +static void print_time(const char *field, __s64 tv_sec, __s32 tv_nsec) +{ + struct tm tm; + time_t tim; + char buffer[100]; + int len; + + tim = tv_sec; + if (!localtime_r(&tim, &tm)) { + perror("localtime_r"); + exit(1); + } + len = strftime(buffer, 100, "%F %T", &tm); + if (len == 0) { + perror("strftime"); + exit(1); + } + printf("%s", field); + fwrite(buffer, 1, len, stdout); + printf(".%09u", tv_nsec); + len = strftime(buffer, 100, "%z", &tm); + if (len == 0) { + perror("strftime2"); + exit(1); + } + fwrite(buffer, 1, len, stdout); + printf("\n"); +} + +static void dump_statx(struct statx *stx) +{ + char buffer[256], ft = '?'; + + printf("results=%x\n", stx->stx_mask); + + printf(" "); + if (stx->stx_mask & STATX_SIZE) + printf(" Size: %-15llu", (unsigned long long)stx->stx_size); + if (stx->stx_mask & STATX_BLOCKS) + printf(" Blocks: %-10llu", (unsigned long long)stx->stx_blocks); + printf(" IO Block: %-6llu ", (unsigned long long)stx->stx_blksize); + if (stx->stx_mask & STATX_MODE) { + switch (stx->stx_mode & S_IFMT) { + case S_IFIFO: printf(" FIFO\n"); ft = 'p'; break; + case S_IFCHR: printf(" character special file\n"); ft = 'c'; break; + case S_IFDIR: printf(" directory\n"); ft = 'd'; break; + case S_IFBLK: printf(" block special file\n"); ft = 'b'; break; + case S_IFREG: printf(" regular file\n"); ft = '-'; break; + case S_IFLNK: printf(" symbolic link\n"); ft = 'l'; break; + case S_IFSOCK: printf(" socket\n"); ft = 's'; break; + default: + printf("unknown type (%o)\n", stx->stx_mode & S_IFMT); + break; + } + } + + sprintf(buffer, "%02x:%02x", stx->stx_dev_major, stx->stx_dev_minor); + printf("Device: %-15s", buffer); + if (stx->stx_mask & STATX_INO) + printf(" Inode: %-11llu", (unsigned long long) stx->stx_ino); + if (stx->stx_mask & STATX_SIZE) + printf(" Links: %-5u", stx->stx_nlink); + switch (stx->stx_mask & STATX_MODE) { + case S_IFBLK: + case S_IFCHR: + printf(" Device type: %u,%u", stx->stx_rdev_major, stx->stx_rdev_minor); + break; + } + printf("\n"); + + if (stx->stx_mask & STATX_MODE) + printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c) ", + stx->stx_mode & 07777, + ft, + stx->stx_mode & S_IRUSR ? 'r' : '-', + stx->stx_mode & S_IWUSR ? 'w' : '-', + stx->stx_mode & S_IXUSR ? 'x' : '-', + stx->stx_mode & S_IRGRP ? 'r' : '-', + stx->stx_mode & S_IWGRP ? 'w' : '-', + stx->stx_mode & S_IXGRP ? 'x' : '-', + stx->stx_mode & S_IROTH ? 'r' : '-', + stx->stx_mode & S_IWOTH ? 'w' : '-', + stx->stx_mode & S_IXOTH ? 'x' : '-'); + if (stx->stx_mask & STATX_UID) + printf("Uid: %5d ", stx->stx_uid); + if (stx->stx_mask & STATX_GID) + printf("Gid: %5d\n", stx->stx_gid); + + if (stx->stx_mask & STATX_ATIME) + print_time("Access: ", stx->stx_atime_s, stx->stx_atime_ns); + if (stx->stx_mask & STATX_MTIME) + print_time("Modify: ", stx->stx_mtime_s, stx->stx_mtime_ns); + if (stx->stx_mask & STATX_CTIME) + print_time("Change: ", stx->stx_ctime_s, stx->stx_ctime_ns); + if (stx->stx_mask & STATX_BTIME) + print_time(" Birth: ", stx->stx_btime_s, stx->stx_btime_ns); + + if (stx->stx_mask & STATX_VERSION) + printf("Data version: %llxh\n", + (unsigned long long)stx->stx_version); + + if (stx->stx_attributes) { + unsigned char bits; + int loop, byte; + + static char attr_representation[64 + 1] = + /* STATX_ATTR_ flags: */ + "????????" /* 63-56 */ + "????????" /* 55-48 */ + "????????" /* 47-40 */ + "????????" /* 39-32 */ + "????????" /* 31-24 0x00000000-ff000000 */ + "???????u" /* 23-16 0x00000000-00ff0000 */ + "mfrke?AU" /* 15- 8 0x00000000-0000ff00 */ + "?dai?c??" /* 7- 0 0x00000000-000000ff */ + ; + + printf("Attributes: %016llx (", stx->stx_attributes); + for (byte = 64 - 8; byte >= 0; byte -= 8) { + bits = stx->stx_attributes >> byte; + for (loop = 7; loop >= 0; loop--) { + int bit = byte + loop; + + if (bits & 0x80) + putchar(attr_representation[63 - bit]); + else + putchar('-'); + bits <<= 1; + } + if (byte) + putchar(' '); + } + printf(")\n"); + } + + printf("IO-blocksize: blksize=%u\n", stx->stx_blksize); +} + +static void dump_hex(unsigned long long *data, int from, int to) +{ + unsigned offset, print_offset = 1, col = 0; + + from /= 8; + to = (to + 7) / 8; + + for (offset = from; offset < to; offset++) { + if (print_offset) { + printf("%04x: ", offset * 8); + print_offset = 0; + } + printf("%016llx", data[offset]); + col++; + if ((col & 3) == 0) { + printf("\n"); + print_offset = 1; + } else { + printf(" "); + } + } + + if (!print_offset) + printf("\n"); +} + +int main(int argc, char **argv) +{ + struct statx stx; + int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW; + + unsigned int mask = STATX_ALL; + + for (argv++; *argv; argv++) { + if (strcmp(*argv, "-F") == 0) { + atflag |= AT_STATX_FORCE_SYNC; + continue; + } + if (strcmp(*argv, "-D") == 0) { + atflag |= AT_STATX_DONT_SYNC; + continue; + } + if (strcmp(*argv, "-L") == 0) { + atflag &= ~AT_SYMLINK_NOFOLLOW; + continue; + } + if (strcmp(*argv, "-O") == 0) { + mask &= ~STATX_BASIC_STATS; + continue; + } + if (strcmp(*argv, "-A") == 0) { + atflag |= AT_NO_AUTOMOUNT; + continue; + } + if (strcmp(*argv, "-R") == 0) { + raw = 1; + continue; + } + + memset(&stx, 0xbf, sizeof(stx)); + ret = statx(AT_FDCWD, *argv, atflag, mask, &stx); + printf("statx(%s) = %d\n", *argv, ret); + if (ret < 0) { + perror(*argv); + exit(1); + } + + if (raw) + dump_hex((unsigned long long *)&stx, 0, sizeof(stx)); + + dump_statx(&stx); + } + return 0; +} ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells @ 2016-11-17 18:39 ` Jeff Layton 2016-11-18 2:32 ` Andreas Dilger 2016-11-18 8:59 ` David Howells 2016-11-17 23:40 ` Dave Chinner ` (4 subsequent siblings) 5 siblings, 2 replies; 52+ messages in thread From: Jeff Layton @ 2016-11-17 18:39 UTC (permalink / raw) To: David Howells, linux-fsdevel; +Cc: linux-kernel On Thu, 2016-11-17 at 13:35 +0000, David Howells wrote: > Add a system call to make extended file information available, including > file creation, data version and some attribute flags where available > through the underlying filesystem. > > > ======== > OVERVIEW > ======== > > The idea was initially proposed as a set of xattrs that could be retrieved > with getxattr(), but the general preferance proved to be for a new syscall > with an extended stat structure. > > This has a number of uses: > > (1) Better support for the y2038 problem [Arnd Bergmann]. > > (2) Creation time: The SMB protocol carries the creation time, which could > be exported by Samba, which will in turn help CIFS make use of > FS-Cache as that can be used for coherency data. > > This is also specified in NFSv4 as a recommended attribute and could > be exported by NFSD [Steve French]. > > (3) Lightweight stat: Ask for just those details of interest, and allow a > netfs (such as NFS) to approximate anything not of interest, possibly > without going to the server [Trond Myklebust, Ulrich Drepper, Andreas > Dilger]. > > (4) Heavyweight stat: Force a netfs to go to the server, even if it thinks > its cached attributes are up to date [Trond Myklebust]. > > (5) Data version number: Could be used by userspace NFS servers [Aneesh > Kumar]. > > Can also be used to modify fill_post_wcc() in NFSD which retrieves > i_version directly, but has just called vfs_getattr(). It could get > it from the kstat struct if it used vfs_xgetattr() instead. > > (6) BSD stat compatibility: Including more fields from the BSD stat such > as creation time (st_btime) and inode generation number (st_gen) > [Jeremy Allison, Bernd Schubert]. > > (7) Inode generation number: Useful for FUSE and userspace NFS servers > [Bernd Schubert]. This was asked for but later deemed unnecessary > with the open-by-handle capability available > > (8) Extra coherency data may be useful in making backups [Andreas Dilger]. > > (9) Allow the filesystem to indicate what it can/cannot provide: A > filesystem can now say it doesn't support a standard stat feature if > that isn't available, so if, for instance, inode numbers or UIDs don't > exist or are fabricated locally... > > (10) Make the fields a consistent size on all arches and make them large. > > (11) Store a 16-byte volume ID in the superblock that can be returned in > struct xstat [Steve French]. > > (12) Include granularity fields in the time data to indicate the > granularity of each of the times (NFSv4 time_delta) [Steve French]. > > (13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. > Note that the Linux IOC flags are a mess and filesystems such as Ext4 > define flags that aren't in linux/fs.h, so translation in the kernel > may be a necessity (or, possibly, we provide the filesystem type too). > > (14) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer, > Michael Kerrisk]. > > (15) Spare space, request flags and information flags are provided for > future expansion. > > Note that not all of the above are implemented here. > > > =============== > NEW SYSTEM CALL > =============== > > The new system call is: > > int ret = statx(int dfd, > const char *filename, > unsigned int flags, > unsigned int mask, > struct statx *buffer); > > The dfd, filename and flags parameters indicate the file to query. There > is no equivalent of lstat() as that can be emulated with statx() by passing > AT_SYMLINK_NOFOLLOW in flags. There is also no equivalent of fstat() as > that can be emulated by passing a NULL filename to statx() with the fd of > interest in dfd. > > AT_STATX_FORCE_SYNC can be set in flags. This will require a network > filesystem to synchronise its attributes with the server. > > AT_STATX_DONT_SYNC can be set in flags. This will suppress synchronisation > with the server in a network filesystem. The resulting values should be > considered approximate. > > If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for > stat() on that filesystem. > We also need to specify here what happens if both bits are set. Should that be -EINVAL? > mask is a bitmask indicating the fields in struct statx that are of > interest to the caller. The user should set this to STATX_BASIC_STATS to > get the basic set returned by stat(). It should be note that asking for > more information may entail more I/O operations. > > buffer points to the destination for the data. This must be 256 bytes in > size. > > > ====================== > MAIN ATTRIBUTES RECORD > ====================== > > The following structures are defined in which to return the main attribute > set: > > struct statx { > __u32 stx_mask; > __u32 stx_blksize; > __u64 stx_attributes; > __u32 stx_nlink; > __u32 stx_uid; > __u32 stx_gid; > __u16 stx_mode; > __u16 __spare0[1]; > __u64 stx_ino; > __u64 stx_size; > __u64 stx_blocks; > __u64 stx_version; > __s64 stx_atime; > __s64 stx_btime; > __s64 stx_ctime; > __s64 stx_mtime; > __s32 stx_atime_ns; > __s32 stx_btime_ns; > __s32 stx_ctime_ns; > __s32 stx_mtime_ns; > __u32 stx_rdev_major; > __u32 stx_rdev_minor; > __u32 stx_dev_major; > __u32 stx_dev_minor; > __u64 __spare1[16]; > }; > > The defined bits in request_mask and stx_mask are: > > STATX_TYPE Want/got stx_mode & S_IFMT > STATX_MODE Want/got stx_mode & ~S_IFMT > STATX_NLINK Want/got stx_nlink > STATX_UID Want/got stx_uid > STATX_GID Want/got stx_gid > STATX_ATIME Want/got stx_atime{,_ns} > STATX_MTIME Want/got stx_mtime{,_ns} > STATX_CTIME Want/got stx_ctime{,_ns} > STATX_INO Want/got stx_ino > STATX_SIZE Want/got stx_size > STATX_BLOCKS Want/got stx_blocks > STATX_BASIC_STATS [The stuff in the normal stat struct] > STATX_BTIME Want/got stx_btime{,_ns} > STATX_VERSION Want/got stx_version > STATX_ALL [All currently available stuff] > > stx_btime is the file creation time; stx_version is the data version number > (i_version); stx_mask is a bitmask indicating the data provided; and > __spares*[] are where as-yet undefined fields can be placed. > > Time fields are split into separate seconds and nanoseconds fields to make > packing easier and the granularities can be queried with the filesystem > info system call. Note that times will be negative if before 1970; in such > a case, the nanosecond fields will also be negative if not zero. > > The bits defined in the stx_attributes field convey information about a > file, how it is accessed, where it is and what it does. The following > attributes map to FS_*_FL flags and are the same numerical value: > > STATX_ATTR_COMPRESSED File is compressed by the fs > STATX_ATTR_IMMUTABLE File is marked immutable > STATX_ATTR_APPEND File is append-only > STATX_ATTR_NODUMP File is not to be dumped > STATX_ATTR_ENCRYPTED File requires key to decrypt in fs > > The supported flags are listed by: > > STATX_ATTR_FS_IOC_FLAGS > > [Are any other IOC flags of sufficient general interest to be exposed > through this interface?] > > New flags include: > > STATX_ATTR_NONUNIX_OWNERSHIP File doesn't have Unixy ownership > STATX_ATTR_HAS_ACL File has an ACL > STATX_ATTR_KERNEL_API File is kernel API (eg: procfs/sysfs) > STATX_ATTR_REMOTE File is remote and needs network > STATX_ATTR_FABRICATED File was made up by fs > STATX_ATTR_AUTOMOUNT Object is an automount trigger > STATX_ATTR_UNLISTED_DENTS Dir: Lookup may find files getdents doesn't > > These are for the use of GUI tools that might want to mark files specially, > depending on what they are. > > Fields in struct statx come in a number of classes: > > (0) stx_dev_*, stx_blksize. > > These are local system information and are always available. > > (1) stx_mode, stx_nlinks, stx_uid, stx_gid, stx_[amc]time*, stx_ino, > stx_size, stx_blocks. > > These will be returned whether the caller asks for them or not. The > corresponding bits in stx_mask will be set to indicate whether they > actually have valid values. > > If the caller didn't ask for them, then they may be approximated. For > example, NFS won't waste any time updating them from the server, > unless as a byproduct of updating something requested. > > If the values don't actually exist for the underlying object (such as > UID or GID on a DOS file), then the bit won't be set in the stx_mask, > even if the caller asked for the value. In such a case, the returned > value will be a fabrication. > > Note that there are instances where the type might not be valid, for > instance Windows reparse points. > > (2) stx_rdev_*. > > This will be set only if stx_mode indicates we're looking at a > blockdev or a chardev, otherwise will be 0. > > (3) stx_btime*, stx_version. > > Similar to (1), except these will be set to 0 if they don't exist. > > > ======= > TESTING > ======= > > The following test program can be used to test the statx system call: > > samples/statx/test-statx.c > > Just compile and run, passing it paths to the files you want to examine. > The file is built automatically if CONFIG_SAMPLES is enabled. > > Here's some example output. Firstly, an NFS directory that crosses to > another FSID. Note that the FABRICATED and AUTOMOUNT info flags are set. > The former because the directory is invented locally as we don't see the > underlying dir on the server, the latter because transiting this directory > will cause d_automount to be invoked by the VFS. > > [root@andromeda tmp]# ./samples/statx/test-statx -A /warthog/data > statx(/warthog/data) = 0 > results=17ff > Size: 4096 Blocks: 8 IO Block: 1048576 directory > Device: 00:26 Inode: 1703937 Links: 124 > Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041 > Access: 2016-11-10 15:52:11.219935864+0000 > Modify: 2016-11-10 08:07:32.482314928+0000 > Change: 2016-11-10 08:07:32.482314928+0000 > Data version: 58242ac41cbf8ab0h > Attributes: 000000000000e000 (-------- -------- -------- -------- -------- -------- mfr----- --------) > IO-blocksize: blksize=1048576 > > Secondly, the result of automounting on that directory. > > [root@andromeda tmp]# ./samples/statx/test-statx /warthog/data > statx(/warthog/data) = 0 > results=17ff > Size: 4096 Blocks: 8 IO Block: 1048576 directory > Device: 00:27 Inode: 2 Links: 124 > Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041 > Access: 2016-11-10 15:52:11.219935864+0000 > Modify: 2016-11-10 08:07:32.482314928+0000 > Change: 2016-11-10 08:07:32.482314928+0000 > Data version: 58242ac41cbf8ab0h > Attributes: 0000000000002000 (-------- -------- -------- -------- -------- -------- --r----- --------) > IO-blocksize: blksize=1048576 > > Signed-off-by: David Howells <dhowells@redhat.com> > --- > > arch/x86/entry/syscalls/syscall_32.tbl | 1 > arch/x86/entry/syscalls/syscall_64.tbl | 1 > fs/exportfs/expfs.c | 4 > fs/stat.c | 294 +++++++++++++++++++++++++++++--- > include/linux/fs.h | 5 - > include/linux/stat.h | 19 +- > include/linux/syscalls.h | 3 > include/uapi/linux/fcntl.h | 2 > include/uapi/linux/stat.h | 124 +++++++++++++ > samples/Kconfig | 5 + > samples/Makefile | 3 > samples/statx/Makefile | 10 + > samples/statx/test-statx.c | 248 +++++++++++++++++++++++++++ > 13 files changed, 679 insertions(+), 40 deletions(-) > create mode 100644 samples/statx/Makefile > create mode 100644 samples/statx/test-statx.c > > diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl > index 2b3618542544..9ba050fe47f3 100644 > --- a/arch/x86/entry/syscalls/syscall_32.tbl > +++ b/arch/x86/entry/syscalls/syscall_32.tbl > @@ -389,3 +389,4 @@ > 380 i386 pkey_mprotect sys_pkey_mprotect > 381 i386 pkey_alloc sys_pkey_alloc > 382 i386 pkey_free sys_pkey_free > +383 i386 statx sys_statx > diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl > index e93ef0b38db8..5aef183e2f85 100644 > --- a/arch/x86/entry/syscalls/syscall_64.tbl > +++ b/arch/x86/entry/syscalls/syscall_64.tbl > @@ -338,6 +338,7 @@ > 329 common pkey_mprotect sys_pkey_mprotect > 330 common pkey_alloc sys_pkey_alloc > 331 common pkey_free sys_pkey_free > +332 common statx sys_statx > > # > # x32-specific system call numbers start at 512 to avoid cache impact > diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c > index a4b531be9168..2acc31751248 100644 > --- a/fs/exportfs/expfs.c > +++ b/fs/exportfs/expfs.c > @@ -299,7 +299,9 @@ static int get_name(const struct path *path, char *name, struct dentry *child) > * filesystem supports 64-bit inode numbers. So we need to > * actually call ->getattr, not just read i_ino: > */ > - error = vfs_getattr_nosec(&child_path, &stat); > + stat.query_flags = 0; > + stat.request_mask = STATX_BASIC_STATS; > + error = vfs_xgetattr_nosec(&child_path, &stat); > if (error) > return error; > buffer.ino = stat.ino; > diff --git a/fs/stat.c b/fs/stat.c > index bc045c7994e1..78c0a5086038 100644 > --- a/fs/stat.c > +++ b/fs/stat.c > @@ -18,6 +18,15 @@ > #include <asm/uaccess.h> > #include <asm/unistd.h> > > +/** > + * generic_fillattr - Fill in the basic attributes from the inode struct > + * @inode: Inode to use as the source > + * @stat: Where to fill in the attributes > + * > + * Fill in the basic attributes in the kstat structure from data that's to be > + * found on the VFS inode structure. This is the default if no getattr inode > + * operation is supplied. > + */ > void generic_fillattr(struct inode *inode, struct kstat *stat) > { > stat->dev = inode->i_sb->s_dev; > @@ -27,87 +36,189 @@ void generic_fillattr(struct inode *inode, struct kstat *stat) > stat->uid = inode->i_uid; > stat->gid = inode->i_gid; > stat->rdev = inode->i_rdev; > - stat->size = i_size_read(inode); > - stat->atime = inode->i_atime; > stat->mtime = inode->i_mtime; > stat->ctime = inode->i_ctime; > - stat->blksize = (1 << inode->i_blkbits); > + stat->size = i_size_read(inode); > stat->blocks = inode->i_blocks; > -} > + stat->blksize = 1 << inode->i_blkbits; > > + stat->result_mask |= STATX_BASIC_STATS; > + if (IS_NOATIME(inode)) > + stat->result_mask &= ~STATX_ATIME; > + else > + stat->atime = inode->i_atime; > + > + if (IS_AUTOMOUNT(inode)) > + stat->attributes |= STATX_ATTR_AUTOMOUNT; > +} > EXPORT_SYMBOL(generic_fillattr); > > /** > - * vfs_getattr_nosec - getattr without security checks > + * vfs_xgetattr_nosec - getattr without security checks > * @path: file to get attributes from > * @stat: structure to return attributes in > * > * Get attributes without calling security_inode_getattr. > * > - * Currently the only caller other than vfs_getattr is internal to the > - * filehandle lookup code, which uses only the inode number and returns > - * no attributes to any user. Any other code probably wants > - * vfs_getattr. > + * Currently the only caller other than vfs_xgetattr is internal to the > + * filehandle lookup code, which uses only the inode number and returns no > + * attributes to any user. Any other code probably wants vfs_xgetattr. > + * > + * The caller must set stat->request_mask to indicate what they want and > + * stat->query_flags to indicate whether the server should be queried. > */ > -int vfs_getattr_nosec(struct path *path, struct kstat *stat) > +int vfs_xgetattr_nosec(struct path *path, struct kstat *stat) > { > struct inode *inode = d_backing_inode(path->dentry); > > + stat->query_flags &= ~KSTAT_QUERY_FLAGS; > + > + stat->result_mask = 0; > + stat->attributes = 0; > if (inode->i_op->getattr) > return inode->i_op->getattr(path->mnt, path->dentry, stat); > > generic_fillattr(inode, stat); > return 0; > } > +EXPORT_SYMBOL(vfs_xgetattr_nosec); > > -EXPORT_SYMBOL(vfs_getattr_nosec); > - > -int vfs_getattr(struct path *path, struct kstat *stat) > +/* > + * vfs_xgetattr - Get the enhanced basic attributes of a file > + * @path: The file of interest > + * @stat: Where to return the statistics > + * > + * Ask the filesystem for a file's attributes. The caller must have preset > + * stat->request_mask and stat->query_flags to indicate what they want. > + * > + * If the file is remote, the filesystem can be forced to update the attributes > + * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags or can > + * suppress the update by passing AT_NO_ATTR_SYNC. > + * > + * Bits must have been set in stat->request_mask to indicate which attributes > + * the caller wants retrieving. Any such attribute not requested may be > + * returned anyway, but the value may be approximate, and, if remote, may not > + * have been synchronised with the server. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_xgetattr(struct path *path, struct kstat *stat) > { > int retval; > > retval = security_inode_getattr(path); > if (retval) > return retval; > - return vfs_getattr_nosec(path, stat); > + return vfs_xgetattr_nosec(path, stat); > } > +EXPORT_SYMBOL(vfs_xgetattr); > > +/** > + * vfs_getattr - Get the basic attributes of a file > + * @path: The file of interest > + * @stat: Where to return the statistics > + * > + * Ask the filesystem for a file's attributes. If remote, the filesystem isn't > + * forced to update its files from the backing store. Only the basic set of > + * attributes will be retrieved; anyone wanting more must use vfs_xgetattr(), > + * as must anyone who wants to force attributes to be sync'd with the server. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_getattr(struct path *path, struct kstat *stat) > +{ > + stat->query_flags = 0; > + stat->request_mask = STATX_BASIC_STATS; > + return vfs_xgetattr(path, stat); > +} > EXPORT_SYMBOL(vfs_getattr); > > -int vfs_fstat(unsigned int fd, struct kstat *stat) > +/** > + * vfs_fstatx - Get the enhanced basic attributes by file descriptor > + * @fd: The file descriptor referring to the file of interest > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_xgetattr(). The main difference is > + * that it uses a file descriptor to determine the file location. > + * > + * The caller must have preset stat->query_flags and stat->request_mask as for > + * vfs_xgetattr(). > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_fstatx(unsigned int fd, struct kstat *stat) > { > struct fd f = fdget_raw(fd); > int error = -EBADF; > > if (f.file) { > - error = vfs_getattr(&f.file->f_path, stat); > + error = vfs_xgetattr(&f.file->f_path, stat); > fdput(f); > } > return error; > } > +EXPORT_SYMBOL(vfs_fstatx); > + > +/** > + * vfs_fstat - Get basic attributes by file descriptor > + * @fd: The file descriptor referring to the file of interest > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_getattr(). The main difference is > + * that it uses a file descriptor to determine the file location. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_fstat(unsigned int fd, struct kstat *stat) > +{ > + stat->query_flags = 0; > + stat->request_mask = STATX_BASIC_STATS; > + return vfs_fstatx(fd, stat); > +} > EXPORT_SYMBOL(vfs_fstat); > > -int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, > - int flag) > +/** > + * vfs_statx - Get basic and extra attributes by filename > + * @dfd: A file descriptor representing the base dir for a relative filename > + * @filename: The name of the file of interest > + * @flags: Flags to control the query > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_xgetattr(). The main difference is > + * that it uses a filename and base directory to determine the file location. > + * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a > + * symlink at the given name from being referenced. > + * > + * The caller must have preset stat->request_mask as for vfs_xgetattr(). The > + * flags are also used to load up stat->query_flags. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_statx(int dfd, const char __user *filename, int flags, > + struct kstat *stat) > { > struct path path; > int error = -EINVAL; > - unsigned int lookup_flags = 0; > + unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT; > > - if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | > - AT_EMPTY_PATH)) != 0) > - goto out; > + if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | > + AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0) > + return -EINVAL; > > - if (!(flag & AT_SYMLINK_NOFOLLOW)) > - lookup_flags |= LOOKUP_FOLLOW; > - if (flag & AT_EMPTY_PATH) > + if (flags & AT_SYMLINK_NOFOLLOW) > + lookup_flags &= ~LOOKUP_FOLLOW; > + if (flags & AT_NO_AUTOMOUNT) > + lookup_flags &= ~LOOKUP_AUTOMOUNT; > + if (flags & AT_EMPTY_PATH) > lookup_flags |= LOOKUP_EMPTY; > + stat->query_flags = flags; > + > retry: > error = user_path_at(dfd, filename, lookup_flags, &path); > if (error) > goto out; > > - error = vfs_getattr(&path, stat); > + error = vfs_xgetattr(&path, stat); > path_put(&path); > if (retry_estale(error, lookup_flags)) { > lookup_flags |= LOOKUP_REVAL; > @@ -116,17 +227,65 @@ int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, > out: > return error; > } > +EXPORT_SYMBOL(vfs_statx); > + > +/** > + * vfs_fstatat - Get basic attributes by filename > + * @dfd: A file descriptor representing the base dir for a relative filename > + * @filename: The name of the file of interest > + * @flags: Flags to control the query > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_statx(). The difference is that it > + * preselects basic stats only. The flags are used to load up > + * stat->query_flags in addition to indicating symlink handling during path > + * resolution. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, > + int flags) > +{ > + stat->request_mask = STATX_BASIC_STATS; > + return vfs_statx(dfd, filename, flags, stat); > +} > EXPORT_SYMBOL(vfs_fstatat); > > -int vfs_stat(const char __user *name, struct kstat *stat) > +/** > + * vfs_stat - Get basic attributes by filename > + * @filename: The name of the file of interest > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_statx(). The difference is that it > + * preselects basic stats only, terminal symlinks are followed regardless and a > + * remote filesystem can't be forced to query the server. If such is desired, > + * vfs_statx() should be used instead. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_stat(const char __user *filename, struct kstat *stat) > { > - return vfs_fstatat(AT_FDCWD, name, stat, 0); > + stat->request_mask = STATX_BASIC_STATS; > + return vfs_statx(AT_FDCWD, filename, 0, stat); > } > EXPORT_SYMBOL(vfs_stat); > > +/** > + * vfs_lstat - Get basic attrs by filename, without following terminal symlink > + * @filename: The name of the file of interest > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_statx(). The difference is that it > + * preselects basic stats only, terminal symlinks are note followed regardless > + * and a remote filesystem can't be forced to query the server. If such is > + * desired, vfs_statx() should be used instead. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > int vfs_lstat(const char __user *name, struct kstat *stat) > { > - return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW); > + stat->request_mask = STATX_BASIC_STATS; > + return vfs_statx(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat); > } > EXPORT_SYMBOL(vfs_lstat); > > @@ -141,7 +300,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta > { > static int warncount = 5; > struct __old_kernel_stat tmp; > - > + > if (warncount > 0) { > warncount--; > printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n", > @@ -166,7 +325,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta > #if BITS_PER_LONG == 32 > if (stat->size > MAX_NON_LFS) > return -EOVERFLOW; > -#endif > +#endif > tmp.st_size = stat->size; > tmp.st_atime = stat->atime.tv_sec; > tmp.st_mtime = stat->mtime.tv_sec; > @@ -443,6 +602,79 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename, > } > #endif /* __ARCH_WANT_STAT64 || __ARCH_WANT_COMPAT_STAT64 */ > > +/* > + * Set the statx results. > + */ > +static long statx_set_result(struct kstat *stat, struct statx __user *buffer) > +{ > + uid_t uid = from_kuid_munged(current_user_ns(), stat->uid); > + gid_t gid = from_kgid_munged(current_user_ns(), stat->gid); > + > +#define __put_timestamp(kts, uts) ( \ > + __put_user(kts.tv_sec, uts##_s ) || \ > + __put_user(kts.tv_nsec, uts##_ns )) > + > + if (__put_user(stat->result_mask, &buffer->stx_mask ) || > + __put_user(stat->mode, &buffer->stx_mode ) || > + __clear_user(&buffer->__spare0, sizeof(buffer->__spare0)) || > + __put_user(stat->nlink, &buffer->stx_nlink ) || > + __put_user(uid, &buffer->stx_uid ) || > + __put_user(gid, &buffer->stx_gid ) || > + __put_user(stat->attributes, &buffer->stx_attributes ) || > + __put_user(stat->blksize, &buffer->stx_blksize ) || > + __put_user(MAJOR(stat->rdev), &buffer->stx_rdev_major ) || > + __put_user(MINOR(stat->rdev), &buffer->stx_rdev_minor ) || > + __put_user(MAJOR(stat->dev), &buffer->stx_dev_major ) || > + __put_user(MINOR(stat->dev), &buffer->stx_dev_minor ) || > + __put_timestamp(stat->atime, &buffer->stx_atime ) || > + __put_timestamp(stat->btime, &buffer->stx_btime ) || > + __put_timestamp(stat->ctime, &buffer->stx_ctime ) || > + __put_timestamp(stat->mtime, &buffer->stx_mtime ) || > + __put_user(stat->ino, &buffer->stx_ino ) || > + __put_user(stat->size, &buffer->stx_size ) || > + __put_user(stat->blocks, &buffer->stx_blocks ) || > + __put_user(stat->version, &buffer->stx_version ) || > + __clear_user(&buffer->__spare1, sizeof(buffer->__spare1))) > + return -EFAULT; > + > + return 0; > +} > + > +/** > + * sys_statx - System call to get enhanced stats > + * @dfd: Base directory to pathwalk from *or* fd to stat. > + * @filename: File to stat *or* NULL. > + * @flags: AT_* flags to control pathwalk. > + * @mask: Parts of statx struct actually required. > + * @buffer: Result buffer. > + * > + * Note that if filename is NULL, then it does the equivalent of fstat() using > + * dfd to indicate the file of interest. > + */ > +SYSCALL_DEFINE5(statx, > + int, dfd, const char __user *, filename, unsigned, flags, > + unsigned int, mask, > + struct statx __user *, buffer) > +{ > + struct kstat stat; > + int error; > + > + if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer))) > + return -EFAULT; > + > + memset(&stat, 0, sizeof(stat)); > + stat.query_flags = flags; > + stat.request_mask = mask & STATX_ALL; > + > + if (filename) > + error = vfs_statx(dfd, filename, flags, &stat); > + else > + error = vfs_fstatx(dfd, &stat); > + if (error) > + return error; > + return statx_set_result(&stat, buffer); > +} > + > /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */ > void __inode_add_bytes(struct inode *inode, loff_t bytes) > { > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 16d2b6e874d6..f153199566b4 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -2916,8 +2916,9 @@ extern const struct inode_operations page_symlink_inode_operations; > extern void kfree_link(void *); > extern int generic_readlink(struct dentry *, char __user *, int); > extern void generic_fillattr(struct inode *, struct kstat *); > -int vfs_getattr_nosec(struct path *path, struct kstat *stat); > +extern int vfs_xgetattr_nosec(struct path *path, struct kstat *stat); > extern int vfs_getattr(struct path *, struct kstat *); > +extern int vfs_xgetattr(struct path *, struct kstat *); > void __inode_add_bytes(struct inode *inode, loff_t bytes); > void inode_add_bytes(struct inode *inode, loff_t bytes); > void __inode_sub_bytes(struct inode *inode, loff_t bytes); > @@ -2935,6 +2936,8 @@ extern int vfs_lstat(const char __user *, struct kstat *); > extern int vfs_fstat(unsigned int, struct kstat *); > extern int vfs_fstatat(int , const char __user *, struct kstat *, int); > extern const char *vfs_get_link(struct dentry *, struct delayed_call *); > +extern int vfs_xstat(int, const char __user *, int, struct kstat *); > +extern int vfs_xfstat(unsigned int, struct kstat *); > > extern int __generic_block_fiemap(struct inode *inode, > struct fiemap_extent_info *fieinfo, > diff --git a/include/linux/stat.h b/include/linux/stat.h > index 075cb0c7eb2a..cf25bb5cf754 100644 > --- a/include/linux/stat.h > +++ b/include/linux/stat.h > @@ -19,19 +19,26 @@ > #include <linux/uidgid.h> > > struct kstat { > - u64 ino; > - dev_t dev; > + u32 query_flags; /* Operational flags */ > +#define KSTAT_QUERY_FLAGS (AT_STATX_FORCE_SYNC | AT_STATX_DONT_SYNC) > + u32 request_mask; /* What fields the user asked for */ > + u32 result_mask; /* What fields the user got */ > umode_t mode; > unsigned int nlink; > + uint32_t blksize; /* Preferred I/O size */ > + u64 attributes; > + u64 ino; > + dev_t dev; > + dev_t rdev; > kuid_t uid; > kgid_t gid; > - dev_t rdev; > loff_t size; > - struct timespec atime; > + struct timespec atime; > struct timespec mtime; > struct timespec ctime; > - unsigned long blksize; > - unsigned long long blocks; > + struct timespec btime; /* File creation time */ > + u64 blocks; > + u64 version; /* Data version */ > }; > > #endif > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h > index 91a740f6b884..980c3c9b06f8 100644 > --- a/include/linux/syscalls.h > +++ b/include/linux/syscalls.h > @@ -48,6 +48,7 @@ struct stat; > struct stat64; > struct statfs; > struct statfs64; > +struct statx; > struct __sysctl_args; > struct sysinfo; > struct timespec; > @@ -902,5 +903,7 @@ asmlinkage long sys_pkey_mprotect(unsigned long start, size_t len, > unsigned long prot, int pkey); > asmlinkage long sys_pkey_alloc(unsigned long flags, unsigned long init_val); > asmlinkage long sys_pkey_free(int pkey); > +asmlinkage long sys_statx(int dfd, const char __user *path, unsigned flags, > + unsigned mask, struct statx __user *buffer); > > #endif > diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h > index beed138bd359..c49cb6edaafa 100644 > --- a/include/uapi/linux/fcntl.h > +++ b/include/uapi/linux/fcntl.h > @@ -62,6 +62,8 @@ > #define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */ > #define AT_NO_AUTOMOUNT 0x800 /* Suppress terminal automount traversal */ > #define AT_EMPTY_PATH 0x1000 /* Allow empty relative pathname */ > +#define AT_STATX_FORCE_SYNC 0x2000 /* Force the attributes to be sync'd with the server */ > +#define AT_STATX_DONT_SYNC 0x4000 /* Don't sync attributes with the server */ > > > #endif /* _UAPI_LINUX_FCNTL_H */ > diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h > index 7fec7e36d921..32ea14c1c960 100644 > --- a/include/uapi/linux/stat.h > +++ b/include/uapi/linux/stat.h > @@ -1,6 +1,7 @@ > #ifndef _UAPI_LINUX_STAT_H > #define _UAPI_LINUX_STAT_H > > +#include <linux/types.h> > > #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) > > @@ -41,5 +42,128 @@ > > #endif > > +/* > + * Structures for the extended file attribute retrieval system call > + * (statx()). > + * > + * The caller passes a mask of what they're specifically interested in as a > + * parameter to statx(). What statx() actually got will be indicated in > + * st_mask upon return. > + * > + * For each bit in the mask argument: > + * > + * - if the datum is not supported: > + * > + * - the bit will be cleared, and > + * > + * - the datum will be set to an appropriate fabricated value if one is > + * available (eg. CIFS can take a default uid and gid), otherwise > + * > + * - the field will be cleared; > + * > + * - otherwise, if explicitly requested: > + * > + * - the datum will be synchronised to the server if AT_STATX_FORCE_SYNC is > + * set or if the datum is considered out of date, and > + * > + * - the field will be filled in and the bit will be set; > + * > + * - otherwise, if not requested, but available in approximate form without any > + * effort, it will be filled in anyway, and the bit will be set upon return > + * (it might not be up to date, however, and no attempt will be made to > + * synchronise the internal state first); > + * > + * - otherwise the field and the bit will be cleared before returning. > + * > + * Items in STATX_BASIC_STATS may be marked unavailable on return, but they > + * will have values installed for compatibility purposes so that stat() and > + * co. can be emulated in userspace. > + */ > +struct statx { > + /* 0x00 */ > + __u32 stx_mask; /* What results were written [uncond] */ > + __u32 stx_blksize; /* Preferred general I/O size [uncond] */ > + __u64 stx_attributes; /* Flags conveying information about the file [uncond] */ > + /* 0x10 */ > + __u32 stx_nlink; /* Number of hard links */ > + __u32 stx_uid; /* User ID of owner */ > + __u32 stx_gid; /* Group ID of owner */ > + __u16 stx_mode; /* File mode */ > + __u16 __spare0[1]; > + /* 0x20 */ > + __u64 stx_ino; /* Inode number */ > + __u64 stx_size; /* File size */ > + __u64 stx_blocks; /* Number of 512-byte blocks allocated */ > + __u64 stx_version; /* Data version number */ > + /* 0x40 */ > + __s64 stx_atime_s; /* Last access time */ > + __s64 stx_btime_s; /* File creation time */ > + __s64 stx_ctime_s; /* Last attribute change time */ > + __s64 stx_mtime_s; /* Last data modification time */ > + /* 0x60 */ > + __s32 stx_atime_ns; /* Last access time (ns part) */ > + __s32 stx_btime_ns; /* File creation time (ns part) */ > + __s32 stx_ctime_ns; /* Last attribute change time (ns part) */ > + __s32 stx_mtime_ns; /* Last data modification time (ns part) */ > + /* 0x70 */ > + __u32 stx_rdev_major; /* Device ID of special file [if bdev/cdev] */ > + __u32 stx_rdev_minor; > + __u32 stx_dev_major; /* ID of device containing file [uncond] */ > + __u32 stx_dev_minor; > + /* 0x80 */ > + __u64 __spare1[16]; /* Spare space for future expansion */ > + /* 0x100 */ > +}; > + > +/* > + * Flags to be stx_mask > + * > + * Query request/result mask for statx() and struct statx::stx_mask. > + * > + * These bits should be set in the mask argument of statx() to request > + * particular items when calling statx(). > + */ > +#define STATX_TYPE 0x00000001U /* Want/got stx_mode & S_IFMT */ > +#define STATX_MODE 0x00000002U /* Want/got stx_mode & ~S_IFMT */ > +#define STATX_NLINK 0x00000004U /* Want/got stx_nlink */ > +#define STATX_UID 0x00000008U /* Want/got stx_uid */ > +#define STATX_GID 0x00000010U /* Want/got stx_gid */ > +#define STATX_ATIME 0x00000020U /* Want/got stx_atime */ > +#define STATX_MTIME 0x00000040U /* Want/got stx_mtime */ > +#define STATX_CTIME 0x00000080U /* Want/got stx_ctime */ > +#define STATX_INO 0x00000100U /* Want/got stx_ino */ > +#define STATX_SIZE 0x00000200U /* Want/got stx_size */ > +#define STATX_BLOCKS 0x00000400U /* Want/got stx_blocks */ > +#define STATX_BASIC_STATS 0x000007ffU /* The stuff in the normal stat struct */ > +#define STATX_BTIME 0x00000800U /* Want/got stx_btime */ > +#define STATX_VERSION 0x00001000U /* Want/got stx_version */ > +#define STATX_ALL 0x00001fffU /* All currently supported flags */ > + > +/* > + * Attributes to be found in stx_attributes > + * > + * These give information about the features or the state of a file that might > + * 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 > + * semantically. Where possible, the numerical value is picked to correspond > + * also. > + */ > +#define STATX_ATTR_COMPRESSED 0x00000004 /* [I] File is compressed by the fs */ > +#define STATX_ATTR_IMMUTABLE 0x00000010 /* [I] File is marked immutable */ > +#define STATX_ATTR_APPEND 0x00000020 /* [I] File is append-only */ > +#define STATX_ATTR_NODUMP 0x00000040 /* [I] File is not to be dumped */ > +#define STATX_ATTR_NONUNIX_OWNERSHIP 0x00000100 /* File has non-Unix ownership details */ > +#define STATX_ATTR_HAS_ACL 0x00000200 /* File has an ACL */ > +#define STATX_ATTR_ENCRYPTED 0x00000800 /* [I] File requires key to decrypt in fs */ > +#define STATX_ATTR_FS_IOC_FLAGS 0x00000874 /* Attrs corresponding to FS_*_FL flags */ > + > +#define STATX_ATTR_KERNEL_API 0x00001000 /* File is kernel API (eg: procfs/sysfs) */ > +#define STATX_ATTR_REMOTE 0x00002000 /* File is remote and needs network */ > +#define STATX_ATTR_FABRICATED 0x00004000 /* File was made up by fs and is transient */ > +#define STATX_ATTR_AUTOMOUNT 0x00008000 /* Dir: Automount trigger */ > +#define STATX_ATTR_UNLISTED_DENTS 0x00010000 /* Dir: Lookup may find files getdents doesn't */ > + > > #endif /* _UAPI_LINUX_STAT_H */ > diff --git a/samples/Kconfig b/samples/Kconfig > index a6d2a43bbf2e..94a7488f14ae 100644 > --- a/samples/Kconfig > +++ b/samples/Kconfig > @@ -105,4 +105,9 @@ config SAMPLE_BLACKFIN_GPTIMERS > help > Build samples of blackfin gptimers sample module. > > +config SAMPLE_STATX > + bool "Build example extended-stat using code" > + help > + Build example userspace program to use the new extended-stat syscall. > + > endif # SAMPLES > diff --git a/samples/Makefile b/samples/Makefile > index e17d66d77f09..8eeb15e13413 100644 > --- a/samples/Makefile > +++ b/samples/Makefile > @@ -2,4 +2,5 @@ > > obj-$(CONFIG_SAMPLES) += kobject/ kprobes/ trace_events/ livepatch/ \ > hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ \ > - configfs/ connector/ v4l/ trace_printk/ blackfin/ > + configfs/ connector/ v4l/ trace_printk/ blackfin/ \ > + statx/ > diff --git a/samples/statx/Makefile b/samples/statx/Makefile > new file mode 100644 > index 000000000000..1f80a3d8cf45 > --- /dev/null > +++ b/samples/statx/Makefile > @@ -0,0 +1,10 @@ > +# kbuild trick to avoid linker error. Can be omitted if a module is built. > +obj- := dummy.o > + > +# List of programs to build > +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx > + > +# Tell kbuild to always build the programs > +always := $(hostprogs-y) > + > +HOSTCFLAGS_test-statx.o += -I$(objtree)/usr/include > diff --git a/samples/statx/test-statx.c b/samples/statx/test-statx.c > new file mode 100644 > index 000000000000..2419b33fc15d > --- /dev/null > +++ b/samples/statx/test-statx.c > @@ -0,0 +1,248 @@ > +/* Test the statx() system call > + * > + * Copyright (C) 2015 Red Hat, Inc. All Rights Reserved. > + * Written by David Howells (dhowells@redhat.com) > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public Licence > + * as published by the Free Software Foundation; either version > + * 2 of the Licence, or (at your option) any later version. > + */ > + > +#define _GNU_SOURCE > +#define _ATFILE_SOURCE > +#include <stdio.h> > +#include <stdlib.h> > +#include <string.h> > +#include <unistd.h> > +#include <ctype.h> > +#include <errno.h> > +#include <time.h> > +#include <sys/syscall.h> > +#include <sys/types.h> > +#include <linux/stat.h> > +#include <linux/fcntl.h> > +#include <sys/stat.h> > + > +#define AT_STATX_FORCE_SYNC 0x2000 > +#define AT_STATX_DONT_SYNC 0x4000 > + > +static __attribute__((unused)) > +ssize_t statx(int dfd, const char *filename, unsigned flags, > + unsigned int mask, struct statx *buffer) > +{ > + return syscall(__NR_statx, dfd, filename, flags, mask, buffer); > +} > + > +static void print_time(const char *field, __s64 tv_sec, __s32 tv_nsec) > +{ > + struct tm tm; > + time_t tim; > + char buffer[100]; > + int len; > + > + tim = tv_sec; > + if (!localtime_r(&tim, &tm)) { > + perror("localtime_r"); > + exit(1); > + } > + len = strftime(buffer, 100, "%F %T", &tm); > + if (len == 0) { > + perror("strftime"); > + exit(1); > + } > + printf("%s", field); > + fwrite(buffer, 1, len, stdout); > + printf(".%09u", tv_nsec); > + len = strftime(buffer, 100, "%z", &tm); > + if (len == 0) { > + perror("strftime2"); > + exit(1); > + } > + fwrite(buffer, 1, len, stdout); > + printf("\n"); > +} > + > +static void dump_statx(struct statx *stx) > +{ > + char buffer[256], ft = '?'; > + > + printf("results=%x\n", stx->stx_mask); > + > + printf(" "); > + if (stx->stx_mask & STATX_SIZE) > + printf(" Size: %-15llu", (unsigned long long)stx->stx_size); > + if (stx->stx_mask & STATX_BLOCKS) > + printf(" Blocks: %-10llu", (unsigned long long)stx->stx_blocks); > + printf(" IO Block: %-6llu ", (unsigned long long)stx->stx_blksize); > + if (stx->stx_mask & STATX_MODE) { > + switch (stx->stx_mode & S_IFMT) { > + case S_IFIFO: printf(" FIFO\n"); ft = 'p'; break; > + case S_IFCHR: printf(" character special file\n"); ft = 'c'; break; > + case S_IFDIR: printf(" directory\n"); ft = 'd'; break; > + case S_IFBLK: printf(" block special file\n"); ft = 'b'; break; > + case S_IFREG: printf(" regular file\n"); ft = '-'; break; > + case S_IFLNK: printf(" symbolic link\n"); ft = 'l'; break; > + case S_IFSOCK: printf(" socket\n"); ft = 's'; break; > + default: > + printf("unknown type (%o)\n", stx->stx_mode & S_IFMT); > + break; > + } > + } > + > + sprintf(buffer, "%02x:%02x", stx->stx_dev_major, stx->stx_dev_minor); > + printf("Device: %-15s", buffer); > + if (stx->stx_mask & STATX_INO) > + printf(" Inode: %-11llu", (unsigned long long) stx->stx_ino); > + if (stx->stx_mask & STATX_SIZE) > + printf(" Links: %-5u", stx->stx_nlink); > + switch (stx->stx_mask & STATX_MODE) { > + case S_IFBLK: > + case S_IFCHR: > + printf(" Device type: %u,%u", stx->stx_rdev_major, stx->stx_rdev_minor); > + break; > + } > + printf("\n"); > + > + if (stx->stx_mask & STATX_MODE) > + printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c) ", > + stx->stx_mode & 07777, > + ft, > + stx->stx_mode & S_IRUSR ? 'r' : '-', > + stx->stx_mode & S_IWUSR ? 'w' : '-', > + stx->stx_mode & S_IXUSR ? 'x' : '-', > + stx->stx_mode & S_IRGRP ? 'r' : '-', > + stx->stx_mode & S_IWGRP ? 'w' : '-', > + stx->stx_mode & S_IXGRP ? 'x' : '-', > + stx->stx_mode & S_IROTH ? 'r' : '-', > + stx->stx_mode & S_IWOTH ? 'w' : '-', > + stx->stx_mode & S_IXOTH ? 'x' : '-'); > + if (stx->stx_mask & STATX_UID) > + printf("Uid: %5d ", stx->stx_uid); > + if (stx->stx_mask & STATX_GID) > + printf("Gid: %5d\n", stx->stx_gid); > + > + if (stx->stx_mask & STATX_ATIME) > + print_time("Access: ", stx->stx_atime_s, stx->stx_atime_ns); > + if (stx->stx_mask & STATX_MTIME) > + print_time("Modify: ", stx->stx_mtime_s, stx->stx_mtime_ns); > + if (stx->stx_mask & STATX_CTIME) > + print_time("Change: ", stx->stx_ctime_s, stx->stx_ctime_ns); > + if (stx->stx_mask & STATX_BTIME) > + print_time(" Birth: ", stx->stx_btime_s, stx->stx_btime_ns); > + > + if (stx->stx_mask & STATX_VERSION) > + printf("Data version: %llxh\n", > + (unsigned long long)stx->stx_version); > + > + if (stx->stx_attributes) { > + unsigned char bits; > + int loop, byte; > + > + static char attr_representation[64 + 1] = > + /* STATX_ATTR_ flags: */ > + "????????" /* 63-56 */ > + "????????" /* 55-48 */ > + "????????" /* 47-40 */ > + "????????" /* 39-32 */ > + "????????" /* 31-24 0x00000000-ff000000 */ > + "???????u" /* 23-16 0x00000000-00ff0000 */ > + "mfrke?AU" /* 15- 8 0x00000000-0000ff00 */ > + "?dai?c??" /* 7- 0 0x00000000-000000ff */ > + ; > + > + printf("Attributes: %016llx (", stx->stx_attributes); > + for (byte = 64 - 8; byte >= 0; byte -= 8) { > + bits = stx->stx_attributes >> byte; > + for (loop = 7; loop >= 0; loop--) { > + int bit = byte + loop; > + > + if (bits & 0x80) > + putchar(attr_representation[63 - bit]); > + else > + putchar('-'); > + bits <<= 1; > + } > + if (byte) > + putchar(' '); > + } > + printf(")\n"); > + } > + > + printf("IO-blocksize: blksize=%u\n", stx->stx_blksize); > +} > + > +static void dump_hex(unsigned long long *data, int from, int to) > +{ > + unsigned offset, print_offset = 1, col = 0; > + > + from /= 8; > + to = (to + 7) / 8; > + > + for (offset = from; offset < to; offset++) { > + if (print_offset) { > + printf("%04x: ", offset * 8); > + print_offset = 0; > + } > + printf("%016llx", data[offset]); > + col++; > + if ((col & 3) == 0) { > + printf("\n"); > + print_offset = 1; > + } else { > + printf(" "); > + } > + } > + > + if (!print_offset) > + printf("\n"); > +} > + > +int main(int argc, char **argv) > +{ > + struct statx stx; > + int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW; > + > + unsigned int mask = STATX_ALL; > + > + for (argv++; *argv; argv++) { > + if (strcmp(*argv, "-F") == 0) { > + atflag |= AT_STATX_FORCE_SYNC; > + continue; > + } > + if (strcmp(*argv, "-D") == 0) { > + atflag |= AT_STATX_DONT_SYNC; > + continue; > + } > + if (strcmp(*argv, "-L") == 0) { > + atflag &= ~AT_SYMLINK_NOFOLLOW; > + continue; > + } > + if (strcmp(*argv, "-O") == 0) { > + mask &= ~STATX_BASIC_STATS; > + continue; > + } > + if (strcmp(*argv, "-A") == 0) { > + atflag |= AT_NO_AUTOMOUNT; > + continue; > + } > + if (strcmp(*argv, "-R") == 0) { > + raw = 1; > + continue; > + } > + > + memset(&stx, 0xbf, sizeof(stx)); > + ret = statx(AT_FDCWD, *argv, atflag, mask, &stx); > + printf("statx(%s) = %d\n", *argv, ret); > + if (ret < 0) { > + perror(*argv); > + exit(1); > + } > + > + if (raw) > + dump_hex((unsigned long long *)&stx, 0, sizeof(stx)); > + > + dump_statx(&stx); > + } > + return 0; > +} > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-17 18:39 ` Jeff Layton @ 2016-11-18 2:32 ` Andreas Dilger 2016-11-18 8:59 ` David Howells 1 sibling, 0 replies; 52+ messages in thread From: Andreas Dilger @ 2016-11-18 2:32 UTC (permalink / raw) To: Jeff Layton; +Cc: David Howells, linux-fsdevel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 50331 bytes --] > On Nov 17, 2016, at 11:39 AM, Jeff Layton <jlayton@redhat.com> wrote: > > On Thu, 2016-11-17 at 13:35 +0000, David Howells wrote: >> Add a system call to make extended file information available, including >> file creation, data version and some attribute flags where available >> through the underlying filesystem. >> >> >> ======== >> OVERVIEW >> ======== >> >> The idea was initially proposed as a set of xattrs that could be retrieved >> with getxattr(), but the general preferance proved to be for a new syscall >> with an extended stat structure. >> >> This has a number of uses: >> >> (1) Better support for the y2038 problem [Arnd Bergmann]. >> >> (2) Creation time: The SMB protocol carries the creation time, which could >> be exported by Samba, which will in turn help CIFS make use of >> FS-Cache as that can be used for coherency data. >> >> This is also specified in NFSv4 as a recommended attribute and could >> be exported by NFSD [Steve French]. >> >> (3) Lightweight stat: Ask for just those details of interest, and allow a >> netfs (such as NFS) to approximate anything not of interest, possibly >> without going to the server [Trond Myklebust, Ulrich Drepper, Andreas >> Dilger]. >> >> (4) Heavyweight stat: Force a netfs to go to the server, even if it thinks >> its cached attributes are up to date [Trond Myklebust]. >> >> (5) Data version number: Could be used by userspace NFS servers [Aneesh >> Kumar]. >> >> Can also be used to modify fill_post_wcc() in NFSD which retrieves >> i_version directly, but has just called vfs_getattr(). It could get >> it from the kstat struct if it used vfs_xgetattr() instead. >> >> (6) BSD stat compatibility: Including more fields from the BSD stat such >> as creation time (st_btime) and inode generation number (st_gen) >> [Jeremy Allison, Bernd Schubert]. >> >> (7) Inode generation number: Useful for FUSE and userspace NFS servers >> [Bernd Schubert]. This was asked for but later deemed unnecessary >> with the open-by-handle capability available >> >> (8) Extra coherency data may be useful in making backups [Andreas Dilger]. >> >> (9) Allow the filesystem to indicate what it can/cannot provide: A >> filesystem can now say it doesn't support a standard stat feature if >> that isn't available, so if, for instance, inode numbers or UIDs don't >> exist or are fabricated locally... >> >> (10) Make the fields a consistent size on all arches and make them large. >> >> (11) Store a 16-byte volume ID in the superblock that can be returned in >> struct xstat [Steve French]. >> >> (12) Include granularity fields in the time data to indicate the >> granularity of each of the times (NFSv4 time_delta) [Steve French]. >> >> (13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. >> Note that the Linux IOC flags are a mess and filesystems such as Ext4 >> define flags that aren't in linux/fs.h, so translation in the kernel >> may be a necessity (or, possibly, we provide the filesystem type too). >> >> (14) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer, >> Michael Kerrisk]. >> >> (15) Spare space, request flags and information flags are provided for >> future expansion. >> >> Note that not all of the above are implemented here. >> >> >> =============== >> NEW SYSTEM CALL >> =============== >> >> The new system call is: >> >> int ret = statx(int dfd, >> const char *filename, >> unsigned int flags, >> unsigned int mask, >> struct statx *buffer); >> >> The dfd, filename and flags parameters indicate the file to query. There >> is no equivalent of lstat() as that can be emulated with statx() by passing >> AT_SYMLINK_NOFOLLOW in flags. There is also no equivalent of fstat() as >> that can be emulated by passing a NULL filename to statx() with the fd of >> interest in dfd. >> >> AT_STATX_FORCE_SYNC can be set in flags. This will require a network >> filesystem to synchronise its attributes with the server. >> >> AT_STATX_DONT_SYNC can be set in flags. This will suppress synchronisation >> with the server in a network filesystem. The resulting values should be >> considered approximate. >> >> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for >> stat() on that filesystem. >> > > We also need to specify here what happens if both bits are set. Should > that be -EINVAL? If that is the case, then it doesn't make sense to have two contradictory flags. Pick a default behaviour (i.e. return what is known on the client), and if this is 100% accurate (e.g. local filesystem or filesystem with strong coherency) then it can optionally set the SYNC flag in the returned flags. If the application needs 100% accurate size info, then it can set the SYNC flag in the request and the filesystem may need to do extra work to fetch accurate data from the server. >> mask is a bitmask indicating the fields in struct statx that are of >> interest to the caller. The user should set this to STATX_BASIC_STATS to >> get the basic set returned by stat(). It should be note that asking for >> more information may entail more I/O operations. >> >> buffer points to the destination for the data. This must be 256 bytes in >> size. >> >> >> ====================== >> MAIN ATTRIBUTES RECORD >> ====================== >> >> The following structures are defined in which to return the main attribute >> set: >> >> struct statx { >> __u32 stx_mask; >> __u32 stx_blksize; >> __u64 stx_attributes; >> __u32 stx_nlink; >> __u32 stx_uid; >> __u32 stx_gid; >> __u16 stx_mode; >> __u16 __spare0[1]; >> __u64 stx_ino; >> __u64 stx_size; >> __u64 stx_blocks; >> __u64 stx_version; >> __s64 stx_atime; >> __s64 stx_btime; >> __s64 stx_ctime; >> __s64 stx_mtime; >> __s32 stx_atime_ns; >> __s32 stx_btime_ns; >> __s32 stx_ctime_ns; >> __s32 stx_mtime_ns; >> __u32 stx_rdev_major; >> __u32 stx_rdev_minor; >> __u32 stx_dev_major; >> __u32 stx_dev_minor; >> __u64 __spare1[16]; >> }; >> >> The defined bits in request_mask and stx_mask are: >> >> STATX_TYPE Want/got stx_mode & S_IFMT >> STATX_MODE Want/got stx_mode & ~S_IFMT >> STATX_NLINK Want/got stx_nlink >> STATX_UID Want/got stx_uid >> STATX_GID Want/got stx_gid >> STATX_ATIME Want/got stx_atime{,_ns} >> STATX_MTIME Want/got stx_mtime{,_ns} >> STATX_CTIME Want/got stx_ctime{,_ns} >> STATX_INO Want/got stx_ino >> STATX_SIZE Want/got stx_size >> STATX_BLOCKS Want/got stx_blocks >> STATX_BASIC_STATS [The stuff in the normal stat struct] >> STATX_BTIME Want/got stx_btime{,_ns} >> STATX_VERSION Want/got stx_version >> STATX_ALL [All currently available stuff] >> >> stx_btime is the file creation time; stx_version is the data version number >> (i_version); stx_mask is a bitmask indicating the data provided; and >> __spares*[] are where as-yet undefined fields can be placed. >> >> Time fields are split into separate seconds and nanoseconds fields to make >> packing easier and the granularities can be queried with the filesystem >> info system call. Note that times will be negative if before 1970; in such >> a case, the nanosecond fields will also be negative if not zero. >> >> The bits defined in the stx_attributes field convey information about a >> file, how it is accessed, where it is and what it does. The following >> attributes map to FS_*_FL flags and are the same numerical value: >> >> STATX_ATTR_COMPRESSED File is compressed by the fs >> STATX_ATTR_IMMUTABLE File is marked immutable >> STATX_ATTR_APPEND File is append-only >> STATX_ATTR_NODUMP File is not to be dumped >> STATX_ATTR_ENCRYPTED File requires key to decrypt in fs >> >> The supported flags are listed by: >> >> STATX_ATTR_FS_IOC_FLAGS >> >> [Are any other IOC flags of sufficient general interest to be exposed >> through this interface?] >> >> New flags include: >> >> STATX_ATTR_NONUNIX_OWNERSHIP File doesn't have Unixy ownership >> STATX_ATTR_HAS_ACL File has an ACL >> STATX_ATTR_KERNEL_API File is kernel API (eg: procfs/sysfs) >> STATX_ATTR_REMOTE File is remote and needs network >> STATX_ATTR_FABRICATED File was made up by fs >> STATX_ATTR_AUTOMOUNT Object is an automount trigger >> STATX_ATTR_UNLISTED_DENTS Dir: Lookup may find files getdents doesn't >> >> These are for the use of GUI tools that might want to mark files specially, >> depending on what they are. >> >> Fields in struct statx come in a number of classes: >> >> (0) stx_dev_*, stx_blksize. >> >> These are local system information and are always available. >> >> (1) stx_mode, stx_nlinks, stx_uid, stx_gid, stx_[amc]time*, stx_ino, >> stx_size, stx_blocks. >> >> These will be returned whether the caller asks for them or not. The >> corresponding bits in stx_mask will be set to indicate whether they >> actually have valid values. >> >> If the caller didn't ask for them, then they may be approximated. For >> example, NFS won't waste any time updating them from the server, >> unless as a byproduct of updating something requested. >> >> If the values don't actually exist for the underlying object (such as >> UID or GID on a DOS file), then the bit won't be set in the stx_mask, >> even if the caller asked for the value. In such a case, the returned >> value will be a fabrication. >> >> Note that there are instances where the type might not be valid, for >> instance Windows reparse points. >> >> (2) stx_rdev_*. >> >> This will be set only if stx_mode indicates we're looking at a >> blockdev or a chardev, otherwise will be 0. >> >> (3) stx_btime*, stx_version. >> >> Similar to (1), except these will be set to 0 if they don't exist. >> >> >> ======= >> TESTING >> ======= >> >> The following test program can be used to test the statx system call: >> >> samples/statx/test-statx.c >> >> Just compile and run, passing it paths to the files you want to examine. >> The file is built automatically if CONFIG_SAMPLES is enabled. >> >> Here's some example output. Firstly, an NFS directory that crosses to >> another FSID. Note that the FABRICATED and AUTOMOUNT info flags are set. >> The former because the directory is invented locally as we don't see the >> underlying dir on the server, the latter because transiting this directory >> will cause d_automount to be invoked by the VFS. >> >> [root@andromeda tmp]# ./samples/statx/test-statx -A /warthog/data >> statx(/warthog/data) = 0 >> results=17ff >> Size: 4096 Blocks: 8 IO Block: 1048576 directory >> Device: 00:26 Inode: 1703937 Links: 124 >> Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041 >> Access: 2016-11-10 15:52:11.219935864+0000 >> Modify: 2016-11-10 08:07:32.482314928+0000 >> Change: 2016-11-10 08:07:32.482314928+0000 >> Data version: 58242ac41cbf8ab0h >> Attributes: 000000000000e000 (-------- -------- -------- -------- -------- -------- mfr----- --------) >> IO-blocksize: blksize=1048576 >> >> Secondly, the result of automounting on that directory. >> >> [root@andromeda tmp]# ./samples/statx/test-statx /warthog/data >> statx(/warthog/data) = 0 >> results=17ff >> Size: 4096 Blocks: 8 IO Block: 1048576 directory >> Device: 00:27 Inode: 2 Links: 124 >> Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041 >> Access: 2016-11-10 15:52:11.219935864+0000 >> Modify: 2016-11-10 08:07:32.482314928+0000 >> Change: 2016-11-10 08:07:32.482314928+0000 >> Data version: 58242ac41cbf8ab0h >> Attributes: 0000000000002000 (-------- -------- -------- -------- -------- -------- --r----- --------) >> IO-blocksize: blksize=1048576 >> >> Signed-off-by: David Howells <dhowells@redhat.com> >> --- >> >> arch/x86/entry/syscalls/syscall_32.tbl | 1 >> arch/x86/entry/syscalls/syscall_64.tbl | 1 >> fs/exportfs/expfs.c | 4 >> fs/stat.c | 294 +++++++++++++++++++++++++++++--- >> include/linux/fs.h | 5 - >> include/linux/stat.h | 19 +- >> include/linux/syscalls.h | 3 >> include/uapi/linux/fcntl.h | 2 >> include/uapi/linux/stat.h | 124 +++++++++++++ >> samples/Kconfig | 5 + >> samples/Makefile | 3 >> samples/statx/Makefile | 10 + >> samples/statx/test-statx.c | 248 +++++++++++++++++++++++++++ >> 13 files changed, 679 insertions(+), 40 deletions(-) >> create mode 100644 samples/statx/Makefile >> create mode 100644 samples/statx/test-statx.c >> >> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl >> index 2b3618542544..9ba050fe47f3 100644 >> --- a/arch/x86/entry/syscalls/syscall_32.tbl >> +++ b/arch/x86/entry/syscalls/syscall_32.tbl >> @@ -389,3 +389,4 @@ >> 380 i386 pkey_mprotect sys_pkey_mprotect >> 381 i386 pkey_alloc sys_pkey_alloc >> 382 i386 pkey_free sys_pkey_free >> +383 i386 statx sys_statx >> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl >> index e93ef0b38db8..5aef183e2f85 100644 >> --- a/arch/x86/entry/syscalls/syscall_64.tbl >> +++ b/arch/x86/entry/syscalls/syscall_64.tbl >> @@ -338,6 +338,7 @@ >> 329 common pkey_mprotect sys_pkey_mprotect >> 330 common pkey_alloc sys_pkey_alloc >> 331 common pkey_free sys_pkey_free >> +332 common statx sys_statx >> >> # >> # x32-specific system call numbers start at 512 to avoid cache impact >> diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c >> index a4b531be9168..2acc31751248 100644 >> --- a/fs/exportfs/expfs.c >> +++ b/fs/exportfs/expfs.c >> @@ -299,7 +299,9 @@ static int get_name(const struct path *path, char *name, struct dentry *child) >> * filesystem supports 64-bit inode numbers. So we need to >> * actually call ->getattr, not just read i_ino: >> */ >> - error = vfs_getattr_nosec(&child_path, &stat); >> + stat.query_flags = 0; >> + stat.request_mask = STATX_BASIC_STATS; >> + error = vfs_xgetattr_nosec(&child_path, &stat); >> if (error) >> return error; >> buffer.ino = stat.ino; >> diff --git a/fs/stat.c b/fs/stat.c >> index bc045c7994e1..78c0a5086038 100644 >> --- a/fs/stat.c >> +++ b/fs/stat.c >> @@ -18,6 +18,15 @@ >> #include <asm/uaccess.h> >> #include <asm/unistd.h> >> >> +/** >> + * generic_fillattr - Fill in the basic attributes from the inode struct >> + * @inode: Inode to use as the source >> + * @stat: Where to fill in the attributes >> + * >> + * Fill in the basic attributes in the kstat structure from data that's to be >> + * found on the VFS inode structure. This is the default if no getattr inode >> + * operation is supplied. >> + */ >> void generic_fillattr(struct inode *inode, struct kstat *stat) >> { >> stat->dev = inode->i_sb->s_dev; >> @@ -27,87 +36,189 @@ void generic_fillattr(struct inode *inode, struct kstat *stat) >> stat->uid = inode->i_uid; >> stat->gid = inode->i_gid; >> stat->rdev = inode->i_rdev; >> - stat->size = i_size_read(inode); >> - stat->atime = inode->i_atime; >> stat->mtime = inode->i_mtime; >> stat->ctime = inode->i_ctime; >> - stat->blksize = (1 << inode->i_blkbits); >> + stat->size = i_size_read(inode); >> stat->blocks = inode->i_blocks; >> -} >> + stat->blksize = 1 << inode->i_blkbits; >> >> + stat->result_mask |= STATX_BASIC_STATS; >> + if (IS_NOATIME(inode)) >> + stat->result_mask &= ~STATX_ATIME; >> + else >> + stat->atime = inode->i_atime; >> + >> + if (IS_AUTOMOUNT(inode)) >> + stat->attributes |= STATX_ATTR_AUTOMOUNT; >> +} >> EXPORT_SYMBOL(generic_fillattr); >> >> /** >> - * vfs_getattr_nosec - getattr without security checks >> + * vfs_xgetattr_nosec - getattr without security checks >> * @path: file to get attributes from >> * @stat: structure to return attributes in >> * >> * Get attributes without calling security_inode_getattr. >> * >> - * Currently the only caller other than vfs_getattr is internal to the >> - * filehandle lookup code, which uses only the inode number and returns >> - * no attributes to any user. Any other code probably wants >> - * vfs_getattr. >> + * Currently the only caller other than vfs_xgetattr is internal to the >> + * filehandle lookup code, which uses only the inode number and returns no >> + * attributes to any user. Any other code probably wants vfs_xgetattr. >> + * >> + * The caller must set stat->request_mask to indicate what they want and >> + * stat->query_flags to indicate whether the server should be queried. >> */ >> -int vfs_getattr_nosec(struct path *path, struct kstat *stat) >> +int vfs_xgetattr_nosec(struct path *path, struct kstat *stat) >> { >> struct inode *inode = d_backing_inode(path->dentry); >> >> + stat->query_flags &= ~KSTAT_QUERY_FLAGS; >> + >> + stat->result_mask = 0; >> + stat->attributes = 0; >> if (inode->i_op->getattr) >> return inode->i_op->getattr(path->mnt, path->dentry, stat); >> >> generic_fillattr(inode, stat); >> return 0; >> } >> +EXPORT_SYMBOL(vfs_xgetattr_nosec); >> >> -EXPORT_SYMBOL(vfs_getattr_nosec); >> - >> -int vfs_getattr(struct path *path, struct kstat *stat) >> +/* >> + * vfs_xgetattr - Get the enhanced basic attributes of a file >> + * @path: The file of interest >> + * @stat: Where to return the statistics >> + * >> + * Ask the filesystem for a file's attributes. The caller must have preset >> + * stat->request_mask and stat->query_flags to indicate what they want. >> + * >> + * If the file is remote, the filesystem can be forced to update the attributes >> + * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags or can >> + * suppress the update by passing AT_NO_ATTR_SYNC. >> + * >> + * Bits must have been set in stat->request_mask to indicate which attributes >> + * the caller wants retrieving. Any such attribute not requested may be >> + * returned anyway, but the value may be approximate, and, if remote, may not >> + * have been synchronised with the server. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_xgetattr(struct path *path, struct kstat *stat) >> { >> int retval; >> >> retval = security_inode_getattr(path); >> if (retval) >> return retval; >> - return vfs_getattr_nosec(path, stat); >> + return vfs_xgetattr_nosec(path, stat); >> } >> +EXPORT_SYMBOL(vfs_xgetattr); >> >> +/** >> + * vfs_getattr - Get the basic attributes of a file >> + * @path: The file of interest >> + * @stat: Where to return the statistics >> + * >> + * Ask the filesystem for a file's attributes. If remote, the filesystem isn't >> + * forced to update its files from the backing store. Only the basic set of >> + * attributes will be retrieved; anyone wanting more must use vfs_xgetattr(), >> + * as must anyone who wants to force attributes to be sync'd with the server. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_getattr(struct path *path, struct kstat *stat) >> +{ >> + stat->query_flags = 0; >> + stat->request_mask = STATX_BASIC_STATS; >> + return vfs_xgetattr(path, stat); >> +} >> EXPORT_SYMBOL(vfs_getattr); >> >> -int vfs_fstat(unsigned int fd, struct kstat *stat) >> +/** >> + * vfs_fstatx - Get the enhanced basic attributes by file descriptor >> + * @fd: The file descriptor referring to the file of interest >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_xgetattr(). The main difference is >> + * that it uses a file descriptor to determine the file location. >> + * >> + * The caller must have preset stat->query_flags and stat->request_mask as for >> + * vfs_xgetattr(). >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_fstatx(unsigned int fd, struct kstat *stat) >> { >> struct fd f = fdget_raw(fd); >> int error = -EBADF; >> >> if (f.file) { >> - error = vfs_getattr(&f.file->f_path, stat); >> + error = vfs_xgetattr(&f.file->f_path, stat); >> fdput(f); >> } >> return error; >> } >> +EXPORT_SYMBOL(vfs_fstatx); >> + >> +/** >> + * vfs_fstat - Get basic attributes by file descriptor >> + * @fd: The file descriptor referring to the file of interest >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_getattr(). The main difference is >> + * that it uses a file descriptor to determine the file location. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_fstat(unsigned int fd, struct kstat *stat) >> +{ >> + stat->query_flags = 0; >> + stat->request_mask = STATX_BASIC_STATS; >> + return vfs_fstatx(fd, stat); >> +} >> EXPORT_SYMBOL(vfs_fstat); >> >> -int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, >> - int flag) >> +/** >> + * vfs_statx - Get basic and extra attributes by filename >> + * @dfd: A file descriptor representing the base dir for a relative filename >> + * @filename: The name of the file of interest >> + * @flags: Flags to control the query >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_xgetattr(). The main difference is >> + * that it uses a filename and base directory to determine the file location. >> + * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a >> + * symlink at the given name from being referenced. >> + * >> + * The caller must have preset stat->request_mask as for vfs_xgetattr(). The >> + * flags are also used to load up stat->query_flags. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_statx(int dfd, const char __user *filename, int flags, >> + struct kstat *stat) >> { >> struct path path; >> int error = -EINVAL; >> - unsigned int lookup_flags = 0; >> + unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT; >> >> - if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | >> - AT_EMPTY_PATH)) != 0) >> - goto out; >> + if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | >> + AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0) >> + return -EINVAL; >> >> - if (!(flag & AT_SYMLINK_NOFOLLOW)) >> - lookup_flags |= LOOKUP_FOLLOW; >> - if (flag & AT_EMPTY_PATH) >> + if (flags & AT_SYMLINK_NOFOLLOW) >> + lookup_flags &= ~LOOKUP_FOLLOW; >> + if (flags & AT_NO_AUTOMOUNT) >> + lookup_flags &= ~LOOKUP_AUTOMOUNT; >> + if (flags & AT_EMPTY_PATH) >> lookup_flags |= LOOKUP_EMPTY; >> + stat->query_flags = flags; >> + >> retry: >> error = user_path_at(dfd, filename, lookup_flags, &path); >> if (error) >> goto out; >> >> - error = vfs_getattr(&path, stat); >> + error = vfs_xgetattr(&path, stat); >> path_put(&path); >> if (retry_estale(error, lookup_flags)) { >> lookup_flags |= LOOKUP_REVAL; >> @@ -116,17 +227,65 @@ int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, >> out: >> return error; >> } >> +EXPORT_SYMBOL(vfs_statx); >> + >> +/** >> + * vfs_fstatat - Get basic attributes by filename >> + * @dfd: A file descriptor representing the base dir for a relative filename >> + * @filename: The name of the file of interest >> + * @flags: Flags to control the query >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_statx(). The difference is that it >> + * preselects basic stats only. The flags are used to load up >> + * stat->query_flags in addition to indicating symlink handling during path >> + * resolution. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, >> + int flags) >> +{ >> + stat->request_mask = STATX_BASIC_STATS; >> + return vfs_statx(dfd, filename, flags, stat); >> +} >> EXPORT_SYMBOL(vfs_fstatat); >> >> -int vfs_stat(const char __user *name, struct kstat *stat) >> +/** >> + * vfs_stat - Get basic attributes by filename >> + * @filename: The name of the file of interest >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_statx(). The difference is that it >> + * preselects basic stats only, terminal symlinks are followed regardless and a >> + * remote filesystem can't be forced to query the server. If such is desired, >> + * vfs_statx() should be used instead. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_stat(const char __user *filename, struct kstat *stat) >> { >> - return vfs_fstatat(AT_FDCWD, name, stat, 0); >> + stat->request_mask = STATX_BASIC_STATS; >> + return vfs_statx(AT_FDCWD, filename, 0, stat); >> } >> EXPORT_SYMBOL(vfs_stat); >> >> +/** >> + * vfs_lstat - Get basic attrs by filename, without following terminal symlink >> + * @filename: The name of the file of interest >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_statx(). The difference is that it >> + * preselects basic stats only, terminal symlinks are note followed regardless >> + * and a remote filesystem can't be forced to query the server. If such is >> + * desired, vfs_statx() should be used instead. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> int vfs_lstat(const char __user *name, struct kstat *stat) >> { >> - return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW); >> + stat->request_mask = STATX_BASIC_STATS; >> + return vfs_statx(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat); >> } >> EXPORT_SYMBOL(vfs_lstat); >> >> @@ -141,7 +300,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta >> { >> static int warncount = 5; >> struct __old_kernel_stat tmp; >> - >> + >> if (warncount > 0) { >> warncount--; >> printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n", >> @@ -166,7 +325,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta >> #if BITS_PER_LONG == 32 >> if (stat->size > MAX_NON_LFS) >> return -EOVERFLOW; >> -#endif >> +#endif >> tmp.st_size = stat->size; >> tmp.st_atime = stat->atime.tv_sec; >> tmp.st_mtime = stat->mtime.tv_sec; >> @@ -443,6 +602,79 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename, >> } >> #endif /* __ARCH_WANT_STAT64 || __ARCH_WANT_COMPAT_STAT64 */ >> >> +/* >> + * Set the statx results. >> + */ >> +static long statx_set_result(struct kstat *stat, struct statx __user *buffer) >> +{ >> + uid_t uid = from_kuid_munged(current_user_ns(), stat->uid); >> + gid_t gid = from_kgid_munged(current_user_ns(), stat->gid); >> + >> +#define __put_timestamp(kts, uts) ( \ >> + __put_user(kts.tv_sec, uts##_s ) || \ >> + __put_user(kts.tv_nsec, uts##_ns )) >> + >> + if (__put_user(stat->result_mask, &buffer->stx_mask ) || >> + __put_user(stat->mode, &buffer->stx_mode ) || >> + __clear_user(&buffer->__spare0, sizeof(buffer->__spare0)) || >> + __put_user(stat->nlink, &buffer->stx_nlink ) || >> + __put_user(uid, &buffer->stx_uid ) || >> + __put_user(gid, &buffer->stx_gid ) || >> + __put_user(stat->attributes, &buffer->stx_attributes ) || >> + __put_user(stat->blksize, &buffer->stx_blksize ) || >> + __put_user(MAJOR(stat->rdev), &buffer->stx_rdev_major ) || >> + __put_user(MINOR(stat->rdev), &buffer->stx_rdev_minor ) || >> + __put_user(MAJOR(stat->dev), &buffer->stx_dev_major ) || >> + __put_user(MINOR(stat->dev), &buffer->stx_dev_minor ) || >> + __put_timestamp(stat->atime, &buffer->stx_atime ) || >> + __put_timestamp(stat->btime, &buffer->stx_btime ) || >> + __put_timestamp(stat->ctime, &buffer->stx_ctime ) || >> + __put_timestamp(stat->mtime, &buffer->stx_mtime ) || >> + __put_user(stat->ino, &buffer->stx_ino ) || >> + __put_user(stat->size, &buffer->stx_size ) || >> + __put_user(stat->blocks, &buffer->stx_blocks ) || >> + __put_user(stat->version, &buffer->stx_version ) || >> + __clear_user(&buffer->__spare1, sizeof(buffer->__spare1))) >> + return -EFAULT; >> + >> + return 0; >> +} >> + >> +/** >> + * sys_statx - System call to get enhanced stats >> + * @dfd: Base directory to pathwalk from *or* fd to stat. >> + * @filename: File to stat *or* NULL. >> + * @flags: AT_* flags to control pathwalk. >> + * @mask: Parts of statx struct actually required. >> + * @buffer: Result buffer. >> + * >> + * Note that if filename is NULL, then it does the equivalent of fstat() using >> + * dfd to indicate the file of interest. >> + */ >> +SYSCALL_DEFINE5(statx, >> + int, dfd, const char __user *, filename, unsigned, flags, >> + unsigned int, mask, >> + struct statx __user *, buffer) >> +{ >> + struct kstat stat; >> + int error; >> + >> + if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer))) >> + return -EFAULT; >> + >> + memset(&stat, 0, sizeof(stat)); >> + stat.query_flags = flags; >> + stat.request_mask = mask & STATX_ALL; >> + >> + if (filename) >> + error = vfs_statx(dfd, filename, flags, &stat); >> + else >> + error = vfs_fstatx(dfd, &stat); >> + if (error) >> + return error; >> + return statx_set_result(&stat, buffer); >> +} >> + >> /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */ >> void __inode_add_bytes(struct inode *inode, loff_t bytes) >> { >> diff --git a/include/linux/fs.h b/include/linux/fs.h >> index 16d2b6e874d6..f153199566b4 100644 >> --- a/include/linux/fs.h >> +++ b/include/linux/fs.h >> @@ -2916,8 +2916,9 @@ extern const struct inode_operations page_symlink_inode_operations; >> extern void kfree_link(void *); >> extern int generic_readlink(struct dentry *, char __user *, int); >> extern void generic_fillattr(struct inode *, struct kstat *); >> -int vfs_getattr_nosec(struct path *path, struct kstat *stat); >> +extern int vfs_xgetattr_nosec(struct path *path, struct kstat *stat); >> extern int vfs_getattr(struct path *, struct kstat *); >> +extern int vfs_xgetattr(struct path *, struct kstat *); >> void __inode_add_bytes(struct inode *inode, loff_t bytes); >> void inode_add_bytes(struct inode *inode, loff_t bytes); >> void __inode_sub_bytes(struct inode *inode, loff_t bytes); >> @@ -2935,6 +2936,8 @@ extern int vfs_lstat(const char __user *, struct kstat *); >> extern int vfs_fstat(unsigned int, struct kstat *); >> extern int vfs_fstatat(int , const char __user *, struct kstat *, int); >> extern const char *vfs_get_link(struct dentry *, struct delayed_call *); >> +extern int vfs_xstat(int, const char __user *, int, struct kstat *); >> +extern int vfs_xfstat(unsigned int, struct kstat *); >> >> extern int __generic_block_fiemap(struct inode *inode, >> struct fiemap_extent_info *fieinfo, >> diff --git a/include/linux/stat.h b/include/linux/stat.h >> index 075cb0c7eb2a..cf25bb5cf754 100644 >> --- a/include/linux/stat.h >> +++ b/include/linux/stat.h >> @@ -19,19 +19,26 @@ >> #include <linux/uidgid.h> >> >> struct kstat { >> - u64 ino; >> - dev_t dev; >> + u32 query_flags; /* Operational flags */ >> +#define KSTAT_QUERY_FLAGS (AT_STATX_FORCE_SYNC | AT_STATX_DONT_SYNC) >> + u32 request_mask; /* What fields the user asked for */ >> + u32 result_mask; /* What fields the user got */ >> umode_t mode; >> unsigned int nlink; >> + uint32_t blksize; /* Preferred I/O size */ >> + u64 attributes; >> + u64 ino; >> + dev_t dev; >> + dev_t rdev; >> kuid_t uid; >> kgid_t gid; >> - dev_t rdev; >> loff_t size; >> - struct timespec atime; >> + struct timespec atime; >> struct timespec mtime; >> struct timespec ctime; >> - unsigned long blksize; >> - unsigned long long blocks; >> + struct timespec btime; /* File creation time */ >> + u64 blocks; >> + u64 version; /* Data version */ >> }; >> >> #endif >> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h >> index 91a740f6b884..980c3c9b06f8 100644 >> --- a/include/linux/syscalls.h >> +++ b/include/linux/syscalls.h >> @@ -48,6 +48,7 @@ struct stat; >> struct stat64; >> struct statfs; >> struct statfs64; >> +struct statx; >> struct __sysctl_args; >> struct sysinfo; >> struct timespec; >> @@ -902,5 +903,7 @@ asmlinkage long sys_pkey_mprotect(unsigned long start, size_t len, >> unsigned long prot, int pkey); >> asmlinkage long sys_pkey_alloc(unsigned long flags, unsigned long init_val); >> asmlinkage long sys_pkey_free(int pkey); >> +asmlinkage long sys_statx(int dfd, const char __user *path, unsigned flags, >> + unsigned mask, struct statx __user *buffer); >> >> #endif >> diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h >> index beed138bd359..c49cb6edaafa 100644 >> --- a/include/uapi/linux/fcntl.h >> +++ b/include/uapi/linux/fcntl.h >> @@ -62,6 +62,8 @@ >> #define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */ >> #define AT_NO_AUTOMOUNT 0x800 /* Suppress terminal automount traversal */ >> #define AT_EMPTY_PATH 0x1000 /* Allow empty relative pathname */ >> +#define AT_STATX_FORCE_SYNC 0x2000 /* Force the attributes to be sync'd with the server */ >> +#define AT_STATX_DONT_SYNC 0x4000 /* Don't sync attributes with the server */ >> >> >> #endif /* _UAPI_LINUX_FCNTL_H */ >> diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h >> index 7fec7e36d921..32ea14c1c960 100644 >> --- a/include/uapi/linux/stat.h >> +++ b/include/uapi/linux/stat.h >> @@ -1,6 +1,7 @@ >> #ifndef _UAPI_LINUX_STAT_H >> #define _UAPI_LINUX_STAT_H >> >> +#include <linux/types.h> >> >> #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) >> >> @@ -41,5 +42,128 @@ >> >> #endif >> >> +/* >> + * Structures for the extended file attribute retrieval system call >> + * (statx()). >> + * >> + * The caller passes a mask of what they're specifically interested in as a >> + * parameter to statx(). What statx() actually got will be indicated in >> + * st_mask upon return. >> + * >> + * For each bit in the mask argument: >> + * >> + * - if the datum is not supported: >> + * >> + * - the bit will be cleared, and >> + * >> + * - the datum will be set to an appropriate fabricated value if one is >> + * available (eg. CIFS can take a default uid and gid), otherwise >> + * >> + * - the field will be cleared; >> + * >> + * - otherwise, if explicitly requested: >> + * >> + * - the datum will be synchronised to the server if AT_STATX_FORCE_SYNC is >> + * set or if the datum is considered out of date, and >> + * >> + * - the field will be filled in and the bit will be set; >> + * >> + * - otherwise, if not requested, but available in approximate form without any >> + * effort, it will be filled in anyway, and the bit will be set upon return >> + * (it might not be up to date, however, and no attempt will be made to >> + * synchronise the internal state first); >> + * >> + * - otherwise the field and the bit will be cleared before returning. >> + * >> + * Items in STATX_BASIC_STATS may be marked unavailable on return, but they >> + * will have values installed for compatibility purposes so that stat() and >> + * co. can be emulated in userspace. >> + */ >> +struct statx { >> + /* 0x00 */ >> + __u32 stx_mask; /* What results were written [uncond] */ >> + __u32 stx_blksize; /* Preferred general I/O size [uncond] */ >> + __u64 stx_attributes; /* Flags conveying information about the file [uncond] */ >> + /* 0x10 */ >> + __u32 stx_nlink; /* Number of hard links */ >> + __u32 stx_uid; /* User ID of owner */ >> + __u32 stx_gid; /* Group ID of owner */ >> + __u16 stx_mode; /* File mode */ >> + __u16 __spare0[1]; >> + /* 0x20 */ >> + __u64 stx_ino; /* Inode number */ >> + __u64 stx_size; /* File size */ >> + __u64 stx_blocks; /* Number of 512-byte blocks allocated */ >> + __u64 stx_version; /* Data version number */ >> + /* 0x40 */ >> + __s64 stx_atime_s; /* Last access time */ >> + __s64 stx_btime_s; /* File creation time */ >> + __s64 stx_ctime_s; /* Last attribute change time */ >> + __s64 stx_mtime_s; /* Last data modification time */ >> + /* 0x60 */ >> + __s32 stx_atime_ns; /* Last access time (ns part) */ >> + __s32 stx_btime_ns; /* File creation time (ns part) */ >> + __s32 stx_ctime_ns; /* Last attribute change time (ns part) */ >> + __s32 stx_mtime_ns; /* Last data modification time (ns part) */ >> + /* 0x70 */ >> + __u32 stx_rdev_major; /* Device ID of special file [if bdev/cdev] */ >> + __u32 stx_rdev_minor; >> + __u32 stx_dev_major; /* ID of device containing file [uncond] */ >> + __u32 stx_dev_minor; >> + /* 0x80 */ >> + __u64 __spare1[16]; /* Spare space for future expansion */ >> + /* 0x100 */ >> +}; >> + >> +/* >> + * Flags to be stx_mask >> + * >> + * Query request/result mask for statx() and struct statx::stx_mask. >> + * >> + * These bits should be set in the mask argument of statx() to request >> + * particular items when calling statx(). >> + */ >> +#define STATX_TYPE 0x00000001U /* Want/got stx_mode & S_IFMT */ >> +#define STATX_MODE 0x00000002U /* Want/got stx_mode & ~S_IFMT */ >> +#define STATX_NLINK 0x00000004U /* Want/got stx_nlink */ >> +#define STATX_UID 0x00000008U /* Want/got stx_uid */ >> +#define STATX_GID 0x00000010U /* Want/got stx_gid */ >> +#define STATX_ATIME 0x00000020U /* Want/got stx_atime */ >> +#define STATX_MTIME 0x00000040U /* Want/got stx_mtime */ >> +#define STATX_CTIME 0x00000080U /* Want/got stx_ctime */ >> +#define STATX_INO 0x00000100U /* Want/got stx_ino */ >> +#define STATX_SIZE 0x00000200U /* Want/got stx_size */ >> +#define STATX_BLOCKS 0x00000400U /* Want/got stx_blocks */ >> +#define STATX_BASIC_STATS 0x000007ffU /* The stuff in the normal stat struct */ >> +#define STATX_BTIME 0x00000800U /* Want/got stx_btime */ >> +#define STATX_VERSION 0x00001000U /* Want/got stx_version */ >> +#define STATX_ALL 0x00001fffU /* All currently supported flags */ >> + >> +/* >> + * Attributes to be found in stx_attributes >> + * >> + * These give information about the features or the state of a file that might >> + * 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 >> + * semantically. Where possible, the numerical value is picked to correspond >> + * also. >> + */ >> +#define STATX_ATTR_COMPRESSED 0x00000004 /* [I] File is compressed by the fs */ >> +#define STATX_ATTR_IMMUTABLE 0x00000010 /* [I] File is marked immutable */ >> +#define STATX_ATTR_APPEND 0x00000020 /* [I] File is append-only */ >> +#define STATX_ATTR_NODUMP 0x00000040 /* [I] File is not to be dumped */ >> +#define STATX_ATTR_NONUNIX_OWNERSHIP 0x00000100 /* File has non-Unix ownership details */ >> +#define STATX_ATTR_HAS_ACL 0x00000200 /* File has an ACL */ >> +#define STATX_ATTR_ENCRYPTED 0x00000800 /* [I] File requires key to decrypt in fs */ >> +#define STATX_ATTR_FS_IOC_FLAGS 0x00000874 /* Attrs corresponding to FS_*_FL flags */ >> + >> +#define STATX_ATTR_KERNEL_API 0x00001000 /* File is kernel API (eg: procfs/sysfs) */ >> +#define STATX_ATTR_REMOTE 0x00002000 /* File is remote and needs network */ >> +#define STATX_ATTR_FABRICATED 0x00004000 /* File was made up by fs and is transient */ >> +#define STATX_ATTR_AUTOMOUNT 0x00008000 /* Dir: Automount trigger */ >> +#define STATX_ATTR_UNLISTED_DENTS 0x00010000 /* Dir: Lookup may find files getdents doesn't */ >> + >> >> #endif /* _UAPI_LINUX_STAT_H */ >> diff --git a/samples/Kconfig b/samples/Kconfig >> index a6d2a43bbf2e..94a7488f14ae 100644 >> --- a/samples/Kconfig >> +++ b/samples/Kconfig >> @@ -105,4 +105,9 @@ config SAMPLE_BLACKFIN_GPTIMERS >> help >> Build samples of blackfin gptimers sample module. >> >> +config SAMPLE_STATX >> + bool "Build example extended-stat using code" >> + help >> + Build example userspace program to use the new extended-stat syscall. >> + >> endif # SAMPLES >> diff --git a/samples/Makefile b/samples/Makefile >> index e17d66d77f09..8eeb15e13413 100644 >> --- a/samples/Makefile >> +++ b/samples/Makefile >> @@ -2,4 +2,5 @@ >> >> obj-$(CONFIG_SAMPLES) += kobject/ kprobes/ trace_events/ livepatch/ \ >> hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ \ >> - configfs/ connector/ v4l/ trace_printk/ blackfin/ >> + configfs/ connector/ v4l/ trace_printk/ blackfin/ \ >> + statx/ >> diff --git a/samples/statx/Makefile b/samples/statx/Makefile >> new file mode 100644 >> index 000000000000..1f80a3d8cf45 >> --- /dev/null >> +++ b/samples/statx/Makefile >> @@ -0,0 +1,10 @@ >> +# kbuild trick to avoid linker error. Can be omitted if a module is built. >> +obj- := dummy.o >> + >> +# List of programs to build >> +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx >> + >> +# Tell kbuild to always build the programs >> +always := $(hostprogs-y) >> + >> +HOSTCFLAGS_test-statx.o += -I$(objtree)/usr/include >> diff --git a/samples/statx/test-statx.c b/samples/statx/test-statx.c >> new file mode 100644 >> index 000000000000..2419b33fc15d >> --- /dev/null >> +++ b/samples/statx/test-statx.c >> @@ -0,0 +1,248 @@ >> +/* Test the statx() system call >> + * >> + * Copyright (C) 2015 Red Hat, Inc. All Rights Reserved. >> + * Written by David Howells (dhowells@redhat.com) >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public Licence >> + * as published by the Free Software Foundation; either version >> + * 2 of the Licence, or (at your option) any later version. >> + */ >> + >> +#define _GNU_SOURCE >> +#define _ATFILE_SOURCE >> +#include <stdio.h> >> +#include <stdlib.h> >> +#include <string.h> >> +#include <unistd.h> >> +#include <ctype.h> >> +#include <errno.h> >> +#include <time.h> >> +#include <sys/syscall.h> >> +#include <sys/types.h> >> +#include <linux/stat.h> >> +#include <linux/fcntl.h> >> +#include <sys/stat.h> >> + >> +#define AT_STATX_FORCE_SYNC 0x2000 >> +#define AT_STATX_DONT_SYNC 0x4000 >> + >> +static __attribute__((unused)) >> +ssize_t statx(int dfd, const char *filename, unsigned flags, >> + unsigned int mask, struct statx *buffer) >> +{ >> + return syscall(__NR_statx, dfd, filename, flags, mask, buffer); >> +} >> + >> +static void print_time(const char *field, __s64 tv_sec, __s32 tv_nsec) >> +{ >> + struct tm tm; >> + time_t tim; >> + char buffer[100]; >> + int len; >> + >> + tim = tv_sec; >> + if (!localtime_r(&tim, &tm)) { >> + perror("localtime_r"); >> + exit(1); >> + } >> + len = strftime(buffer, 100, "%F %T", &tm); >> + if (len == 0) { >> + perror("strftime"); >> + exit(1); >> + } >> + printf("%s", field); >> + fwrite(buffer, 1, len, stdout); >> + printf(".%09u", tv_nsec); >> + len = strftime(buffer, 100, "%z", &tm); >> + if (len == 0) { >> + perror("strftime2"); >> + exit(1); >> + } >> + fwrite(buffer, 1, len, stdout); >> + printf("\n"); >> +} >> + >> +static void dump_statx(struct statx *stx) >> +{ >> + char buffer[256], ft = '?'; >> + >> + printf("results=%x\n", stx->stx_mask); >> + >> + printf(" "); >> + if (stx->stx_mask & STATX_SIZE) >> + printf(" Size: %-15llu", (unsigned long long)stx->stx_size); >> + if (stx->stx_mask & STATX_BLOCKS) >> + printf(" Blocks: %-10llu", (unsigned long long)stx->stx_blocks); >> + printf(" IO Block: %-6llu ", (unsigned long long)stx->stx_blksize); >> + if (stx->stx_mask & STATX_MODE) { >> + switch (stx->stx_mode & S_IFMT) { >> + case S_IFIFO: printf(" FIFO\n"); ft = 'p'; break; >> + case S_IFCHR: printf(" character special file\n"); ft = 'c'; break; >> + case S_IFDIR: printf(" directory\n"); ft = 'd'; break; >> + case S_IFBLK: printf(" block special file\n"); ft = 'b'; break; >> + case S_IFREG: printf(" regular file\n"); ft = '-'; break; >> + case S_IFLNK: printf(" symbolic link\n"); ft = 'l'; break; >> + case S_IFSOCK: printf(" socket\n"); ft = 's'; break; >> + default: >> + printf("unknown type (%o)\n", stx->stx_mode & S_IFMT); >> + break; >> + } >> + } >> + >> + sprintf(buffer, "%02x:%02x", stx->stx_dev_major, stx->stx_dev_minor); >> + printf("Device: %-15s", buffer); >> + if (stx->stx_mask & STATX_INO) >> + printf(" Inode: %-11llu", (unsigned long long) stx->stx_ino); >> + if (stx->stx_mask & STATX_SIZE) >> + printf(" Links: %-5u", stx->stx_nlink); >> + switch (stx->stx_mask & STATX_MODE) { >> + case S_IFBLK: >> + case S_IFCHR: >> + printf(" Device type: %u,%u", stx->stx_rdev_major, stx->stx_rdev_minor); >> + break; >> + } >> + printf("\n"); >> + >> + if (stx->stx_mask & STATX_MODE) >> + printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c) ", >> + stx->stx_mode & 07777, >> + ft, >> + stx->stx_mode & S_IRUSR ? 'r' : '-', >> + stx->stx_mode & S_IWUSR ? 'w' : '-', >> + stx->stx_mode & S_IXUSR ? 'x' : '-', >> + stx->stx_mode & S_IRGRP ? 'r' : '-', >> + stx->stx_mode & S_IWGRP ? 'w' : '-', >> + stx->stx_mode & S_IXGRP ? 'x' : '-', >> + stx->stx_mode & S_IROTH ? 'r' : '-', >> + stx->stx_mode & S_IWOTH ? 'w' : '-', >> + stx->stx_mode & S_IXOTH ? 'x' : '-'); >> + if (stx->stx_mask & STATX_UID) >> + printf("Uid: %5d ", stx->stx_uid); >> + if (stx->stx_mask & STATX_GID) >> + printf("Gid: %5d\n", stx->stx_gid); >> + >> + if (stx->stx_mask & STATX_ATIME) >> + print_time("Access: ", stx->stx_atime_s, stx->stx_atime_ns); >> + if (stx->stx_mask & STATX_MTIME) >> + print_time("Modify: ", stx->stx_mtime_s, stx->stx_mtime_ns); >> + if (stx->stx_mask & STATX_CTIME) >> + print_time("Change: ", stx->stx_ctime_s, stx->stx_ctime_ns); >> + if (stx->stx_mask & STATX_BTIME) >> + print_time(" Birth: ", stx->stx_btime_s, stx->stx_btime_ns); >> + >> + if (stx->stx_mask & STATX_VERSION) >> + printf("Data version: %llxh\n", >> + (unsigned long long)stx->stx_version); >> + >> + if (stx->stx_attributes) { >> + unsigned char bits; >> + int loop, byte; >> + >> + static char attr_representation[64 + 1] = >> + /* STATX_ATTR_ flags: */ >> + "????????" /* 63-56 */ >> + "????????" /* 55-48 */ >> + "????????" /* 47-40 */ >> + "????????" /* 39-32 */ >> + "????????" /* 31-24 0x00000000-ff000000 */ >> + "???????u" /* 23-16 0x00000000-00ff0000 */ >> + "mfrke?AU" /* 15- 8 0x00000000-0000ff00 */ >> + "?dai?c??" /* 7- 0 0x00000000-000000ff */ >> + ; >> + >> + printf("Attributes: %016llx (", stx->stx_attributes); >> + for (byte = 64 - 8; byte >= 0; byte -= 8) { >> + bits = stx->stx_attributes >> byte; >> + for (loop = 7; loop >= 0; loop--) { >> + int bit = byte + loop; >> + >> + if (bits & 0x80) >> + putchar(attr_representation[63 - bit]); >> + else >> + putchar('-'); >> + bits <<= 1; >> + } >> + if (byte) >> + putchar(' '); >> + } >> + printf(")\n"); >> + } >> + >> + printf("IO-blocksize: blksize=%u\n", stx->stx_blksize); >> +} >> + >> +static void dump_hex(unsigned long long *data, int from, int to) >> +{ >> + unsigned offset, print_offset = 1, col = 0; >> + >> + from /= 8; >> + to = (to + 7) / 8; >> + >> + for (offset = from; offset < to; offset++) { >> + if (print_offset) { >> + printf("%04x: ", offset * 8); >> + print_offset = 0; >> + } >> + printf("%016llx", data[offset]); >> + col++; >> + if ((col & 3) == 0) { >> + printf("\n"); >> + print_offset = 1; >> + } else { >> + printf(" "); >> + } >> + } >> + >> + if (!print_offset) >> + printf("\n"); >> +} >> + >> +int main(int argc, char **argv) >> +{ >> + struct statx stx; >> + int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW; >> + >> + unsigned int mask = STATX_ALL; >> + >> + for (argv++; *argv; argv++) { >> + if (strcmp(*argv, "-F") == 0) { >> + atflag |= AT_STATX_FORCE_SYNC; >> + continue; >> + } >> + if (strcmp(*argv, "-D") == 0) { >> + atflag |= AT_STATX_DONT_SYNC; >> + continue; >> + } >> + if (strcmp(*argv, "-L") == 0) { >> + atflag &= ~AT_SYMLINK_NOFOLLOW; >> + continue; >> + } >> + if (strcmp(*argv, "-O") == 0) { >> + mask &= ~STATX_BASIC_STATS; >> + continue; >> + } >> + if (strcmp(*argv, "-A") == 0) { >> + atflag |= AT_NO_AUTOMOUNT; >> + continue; >> + } >> + if (strcmp(*argv, "-R") == 0) { >> + raw = 1; >> + continue; >> + } >> + >> + memset(&stx, 0xbf, sizeof(stx)); >> + ret = statx(AT_FDCWD, *argv, atflag, mask, &stx); >> + printf("statx(%s) = %d\n", *argv, ret); >> + if (ret < 0) { >> + perror(*argv); >> + exit(1); >> + } >> + >> + if (raw) >> + dump_hex((unsigned long long *)&stx, 0, sizeof(stx)); >> + >> + dump_statx(&stx); >> + } >> + return 0; >> +} >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > Jeff Layton <jlayton@redhat.com> > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Andreas [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available @ 2016-11-18 8:59 ` David Howells 0 siblings, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-18 8:59 UTC (permalink / raw) To: Andreas Dilger Cc: dhowells, Jeff Layton, linux-fsdevel, linux-kernel, drepper, linux-api Andreas Dilger <adilger@dilger.ca> wrote: > >> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for > >> stat() on that filesystem. > > > > We also need to specify here what happens if both bits are set. Should > > that be -EINVAL? > > If that is the case, then it doesn't make sense to have two contradictory > flags. Yes it does. There are actually *three* cases, not two. Maybe, rather than a pair of flags, I should stake out a 2-bit field with three possible values. > Pick a default behaviour (i.e. return what is known on the client), The default behaviour has to be what stat() does now for any particular filesystem. statx() is likely to get used to emulate stat() so that stat() can be made to return safe timestamps. If we make it so that statx() cannot do this, it's very likely that we'll see yet another stat() variant syscall being added. > and if this is 100% accurate (e.g. local filesystem or filesystem with > strong coherency) In a netfs, it was 100% accurate at the point the server started transmitting its reply. This may no longer be true - even with something like AFS that has change notifications. > then it can optionally set the SYNC flag in the returned > flags. So you suggest putting the SYNC flag(s) in the request mask rather than sharing the AT_* flag space? > If the application needs 100% accurate size info, then it can set the SYNC > flag in the request and the filesystem may need to do extra work to fetch > accurate data from the server. Note that one of the things that people asked for was a DONT_GO_TO_THE_SERVER_AT_ALL flag. I take it this is your suggested default? David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available @ 2016-11-18 8:59 ` David Howells 0 siblings, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-18 8:59 UTC (permalink / raw) To: Andreas Dilger Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA, Jeff Layton, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, drepper-Re5JQEeQqe8AvxtiuMwx3w, linux-api-u79uwXL29TY76Z2rM5mHXA Andreas Dilger <adilger-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org> wrote: > >> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for > >> stat() on that filesystem. > > > > We also need to specify here what happens if both bits are set. Should > > that be -EINVAL? > > If that is the case, then it doesn't make sense to have two contradictory > flags. Yes it does. There are actually *three* cases, not two. Maybe, rather than a pair of flags, I should stake out a 2-bit field with three possible values. > Pick a default behaviour (i.e. return what is known on the client), The default behaviour has to be what stat() does now for any particular filesystem. statx() is likely to get used to emulate stat() so that stat() can be made to return safe timestamps. If we make it so that statx() cannot do this, it's very likely that we'll see yet another stat() variant syscall being added. > and if this is 100% accurate (e.g. local filesystem or filesystem with > strong coherency) In a netfs, it was 100% accurate at the point the server started transmitting its reply. This may no longer be true - even with something like AFS that has change notifications. > then it can optionally set the SYNC flag in the returned > flags. So you suggest putting the SYNC flag(s) in the request mask rather than sharing the AT_* flag space? > If the application needs 100% accurate size info, then it can set the SYNC > flag in the request and the filesystem may need to do extra work to fetch > accurate data from the server. Note that one of the things that people asked for was a DONT_GO_TO_THE_SERVER_AT_ALL flag. I take it this is your suggested default? David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available @ 2016-11-18 9:25 ` Andreas Dilger 0 siblings, 0 replies; 52+ messages in thread From: Andreas Dilger @ 2016-11-18 9:25 UTC (permalink / raw) To: David Howells Cc: Jeff Layton, linux-fsdevel, linux-kernel, drepper, linux-api [-- Attachment #1: Type: text/plain, Size: 2529 bytes --] On Nov 18, 2016, at 1:59 AM, David Howells <dhowells@redhat.com> wrote: > > Andreas Dilger <adilger@dilger.ca> wrote: > >>>> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for >>>> stat() on that filesystem. >>> >>> We also need to specify here what happens if both bits are set. Should >>> that be -EINVAL? >> >> If that is the case, then it doesn't make sense to have two contradictory >> flags. > > Yes it does. There are actually *three* cases, not two. Maybe, rather > than a pair of flags, I should stake out a 2-bit field with three possible > values. That would probably be better in this case. >> Pick a default behaviour (i.e. return what is known on the client), > > The default behaviour has to be what stat() does now for any particular > filesystem. statx() is likely to get used to emulate stat() so that stat() > can be made to return safe timestamps. If we make it so that statx() cannot > do this, it's very likely that we'll see yet another stat() variant syscall > being added. > >> and if this is 100% accurate (e.g. local filesystem or filesystem with >> strong coherency) > > In a netfs, it was 100% accurate at the point the server started > transmitting its reply. This may no longer be true - even with something > like AFS that has change notifications. Sure, that is always true, even when running with a local filesystem. My distinction here is "whether the client currently has a lock that ensures its copy of the size is correct" vs. "the client has some size that was correct at one point but may be totally incorrect now". >> then it can optionally set the SYNC flag in the returned >> flags. > > So you suggest putting the SYNC flag(s) in the request mask rather than > sharing the AT_* flag space? Sorry, I was conflating flags. >> If the application needs 100% accurate size info, then it can set the SYNC >> flag in the request and the filesystem may need to do extra work to fetch >> accurate data from the server. > > Note that one of the things that people asked for was a > DONT_GO_TO_THE_SERVER_AT_ALL flag. I take it this is your suggested default? Isn't that what NFS does today? In any case, I'm not trying to rewrite NFS semantics here. The main fix would be to have the three-valued two-bit flag so that there aren't two flags that mean opposite things. That would also allow expansion to have a fourth state in the future, if there was a need. Cheers, Andreas [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available @ 2016-11-18 9:25 ` Andreas Dilger 0 siblings, 0 replies; 52+ messages in thread From: Andreas Dilger @ 2016-11-18 9:25 UTC (permalink / raw) To: David Howells Cc: Jeff Layton, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, drepper-Re5JQEeQqe8AvxtiuMwx3w, linux-api-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 2588 bytes --] On Nov 18, 2016, at 1:59 AM, David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: > > Andreas Dilger <adilger-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org> wrote: > >>>> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for >>>> stat() on that filesystem. >>> >>> We also need to specify here what happens if both bits are set. Should >>> that be -EINVAL? >> >> If that is the case, then it doesn't make sense to have two contradictory >> flags. > > Yes it does. There are actually *three* cases, not two. Maybe, rather > than a pair of flags, I should stake out a 2-bit field with three possible > values. That would probably be better in this case. >> Pick a default behaviour (i.e. return what is known on the client), > > The default behaviour has to be what stat() does now for any particular > filesystem. statx() is likely to get used to emulate stat() so that stat() > can be made to return safe timestamps. If we make it so that statx() cannot > do this, it's very likely that we'll see yet another stat() variant syscall > being added. > >> and if this is 100% accurate (e.g. local filesystem or filesystem with >> strong coherency) > > In a netfs, it was 100% accurate at the point the server started > transmitting its reply. This may no longer be true - even with something > like AFS that has change notifications. Sure, that is always true, even when running with a local filesystem. My distinction here is "whether the client currently has a lock that ensures its copy of the size is correct" vs. "the client has some size that was correct at one point but may be totally incorrect now". >> then it can optionally set the SYNC flag in the returned >> flags. > > So you suggest putting the SYNC flag(s) in the request mask rather than > sharing the AT_* flag space? Sorry, I was conflating flags. >> If the application needs 100% accurate size info, then it can set the SYNC >> flag in the request and the filesystem may need to do extra work to fetch >> accurate data from the server. > > Note that one of the things that people asked for was a > DONT_GO_TO_THE_SERVER_AT_ALL flag. I take it this is your suggested default? Isn't that what NFS does today? In any case, I'm not trying to rewrite NFS semantics here. The main fix would be to have the three-valued two-bit flag so that there aren't two flags that mean opposite things. That would also allow expansion to have a fourth state in the future, if there was a need. Cheers, Andreas [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells 2016-11-17 18:39 ` Jeff Layton @ 2016-11-17 23:40 ` Dave Chinner 2016-11-18 3:28 ` Andreas Dilger 2016-11-18 9:53 ` David Howells 2016-11-18 8:48 ` David Howells ` (3 subsequent siblings) 5 siblings, 2 replies; 52+ messages in thread From: Dave Chinner @ 2016-11-17 23:40 UTC (permalink / raw) To: David Howells; +Cc: linux-fsdevel, linux-kernel On Thu, Nov 17, 2016 at 01:35:03PM +0000, David Howells wrote: > Add a system call to make extended file information available, including > file creation, data version and some attribute flags where available > through the underlying filesystem. > > > ======== > OVERVIEW > ======== > > The idea was initially proposed as a set of xattrs that could be retrieved > with getxattr(), but the general preferance proved to be for a new syscall > with an extended stat structure. > > This has a number of uses: > .... > (5) Data version number: Could be used by userspace NFS servers [Aneesh > Kumar]. > > Can also be used to modify fill_post_wcc() in NFSD which retrieves > i_version directly, but has just called vfs_getattr(). It could get > it from the kstat struct if it used vfs_xgetattr() instead. This needs a much clearer name that stx_version as "version" is entirely ambiguous. e.g. Inodes have internal version numbers to disambiguate life cycles. and there are versioning filesystems which have multiple versions of the same file. So if stx_version this is intended to export the internal filesystem inode change counter (i.e. inode->i_version) then lets call it that: stx_modification_count. It's clear and unambiguous as to what it represents, especially as this counter is more than just a "data modification" counter - inode metadata modifications will also cause it to change.... .... > (13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. > Note that the Linux IOC flags are a mess and filesystems such as Ext4 > define flags that aren't in linux/fs.h, so translation in the kernel > may be a necessity (or, possibly, we provide the filesystem type too). And we now also have FS_IOC_FSGETXATTR that extends the flags and information userspace can get from filesystems. It makes little sense to now add xstat() and not add everything this interface also exports... > The defined bits in request_mask and stx_mask are: > > STATX_TYPE Want/got stx_mode & S_IFMT > STATX_MODE Want/got stx_mode & ~S_IFMT > STATX_NLINK Want/got stx_nlink > STATX_UID Want/got stx_uid > STATX_GID Want/got stx_gid > STATX_ATIME Want/got stx_atime{,_ns} > STATX_MTIME Want/got stx_mtime{,_ns} > STATX_CTIME Want/got stx_ctime{,_ns} > STATX_INO Want/got stx_ino > STATX_SIZE Want/got stx_size > STATX_BLOCKS Want/got stx_blocks > STATX_BASIC_STATS [The stuff in the normal stat struct] > STATX_BTIME Want/got stx_btime{,_ns} > STATX_VERSION Want/got stx_version > STATX_ALL [All currently available stuff] What happens when an application uses STATX_ALL from a future kernel that defines more flags than are initially supported, and that application then is run on a kernel that onyl supports the initial fields? > stx_btime is the file creation time; stx_version is the data version number > (i_version); stx_mask is a bitmask indicating the data provided; and > __spares*[] are where as-yet undefined fields can be placed. > > Time fields are split into separate seconds and nanoseconds fields to make > packing easier and the granularities can be queried with the filesystem > info system call. Note that times will be negative if before 1970; in such > a case, the nanosecond fields will also be negative if not zero. So what happens in ten years time when we want to support femptosecond resolution in the timestamp interface? We've got to change everything to 64 bit? Shouldn't we just make everything timestamp related 64 bit? > > The bits defined in the stx_attributes field convey information about a > file, how it is accessed, where it is and what it does. The following > attributes map to FS_*_FL flags and are the same numerical value: Please isolate the new interface flags completely from the FS_*_FL values. We should not repeat the mistake of tying values derived from filesystem specific on-disk values to a user interface. > STATX_ATTR_COMPRESSED File is compressed by the fs > STATX_ATTR_IMMUTABLE File is marked immutable > STATX_ATTR_APPEND File is append-only > STATX_ATTR_NODUMP File is not to be dumped > STATX_ATTR_ENCRYPTED File requires key to decrypt in fs > > The supported flags are listed by: > > STATX_ATTR_FS_IOC_FLAGS Again, we have many more common and extended flags than this. NOATIME and SYNC are two that immediately come to mind as generic flags that should be in this... > > [Are any other IOC flags of sufficient general interest to be exposed > through this interface?] > > New flags include: > > STATX_ATTR_NONUNIX_OWNERSHIP File doesn't have Unixy ownership > STATX_ATTR_HAS_ACL File has an ACL So statx will require us to do ACL lookups? i.e. instead of just reading the inode to get the information, we'll also have to do extended attribute lookups? That's potentially very expensive if the extended attribute is not stored in the inode.... > STATX_ATTR_KERNEL_API File is kernel API (eg: procfs/sysfs) > STATX_ATTR_REMOTE File is remote and needs network > STATX_ATTR_FABRICATED File was made up by fs Every file is fabricated by a filesystem :P Perhaps you're wanting "virtual file" because it is has no physical presence? > Fields in struct statx come in a number of classes: > > (0) stx_dev_*, stx_blksize. > > These are local system information and are always available. What does stx_blksize actually mean? It's completely ambiguous in stat() because we don't actually report the physical block size here - we report the "minimum unit of efficient IO" that we expect applications to use. Please define :P > ======= > TESTING > ======= > > The following test program can be used to test the statx system call: > > samples/statx/test-statx.c > > Just compile and run, passing it paths to the files you want to examine. > The file is built automatically if CONFIG_SAMPLES is enabled. Can we get xfstests written to exercise and validate all this functionality, please? I'd suggest that adding xfs_io support for the statx syscall would be far more useful for xfstests than a standalone test program, too. We already have equivalent stat() functionality in xfs_io and that's used quite a bit in xfstests.... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-17 23:40 ` Dave Chinner @ 2016-11-18 3:28 ` Andreas Dilger 2016-11-18 22:07 ` Dave Chinner 2016-11-18 22:54 ` David Howells 2016-11-18 9:53 ` David Howells 1 sibling, 2 replies; 52+ messages in thread From: Andreas Dilger @ 2016-11-18 3:28 UTC (permalink / raw) To: Dave Chinner; +Cc: David Howells, linux-fsdevel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 9198 bytes --] On Nov 17, 2016, at 4:40 PM, Dave Chinner <david@fromorbit.com> wrote: > > On Thu, Nov 17, 2016 at 01:35:03PM +0000, David Howells wrote: >> Add a system call to make extended file information available, including >> file creation, data version and some attribute flags where available >> through the underlying filesystem. >> >> >> ======== >> OVERVIEW >> ======== >> >> The idea was initially proposed as a set of xattrs that could be retrieved >> with getxattr(), but the general preferance proved to be for a new syscall >> with an extended stat structure. >> >> This has a number of uses: >> > .... >> (5) Data version number: Could be used by userspace NFS servers [Aneesh >> Kumar]. >> >> Can also be used to modify fill_post_wcc() in NFSD which retrieves >> i_version directly, but has just called vfs_getattr(). It could get >> it from the kstat struct if it used vfs_xgetattr() instead. > > This needs a much clearer name that stx_version as "version" is > entirely ambiguous. e.g. Inodes have internal version numbers to > disambiguate life cycles. and there are versioning filesystems > which have multiple versions of the same file. > > So if stx_version this is intended to export the internal filesystem > inode change counter (i.e. inode->i_version) then lets call it that: > stx_modification_count. It's clear and unambiguous as to what it > represents, especially as this counter is more than just a "data > modification" counter - inode metadata modifications will also > cause it to change... Honestly, I don't think "modification count" is necessarily more clear than "version". This value isn't necessarily a counter incremented to hold the number of times the inode was modified, but is used by NFS only to determine whether the inode has been modified from one access to the next. It may not be incremented sequentially for each inode, but rather be a global value across all inodes in the filesystem. It is much more important to clearly document what this version field means. Maybe "stx_modification_version", but I'm fine with "version" as well, since this is what the field is named in the kernel. >> (13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. >> Note that the Linux IOC flags are a mess and filesystems such as Ext4 >> define flags that aren't in linux/fs.h, so translation in the kernel >> may be a necessity (or, possibly, we provide the filesystem type too). > > And we now also have FS_IOC_FSGETXATTR that extends the flags > and information userspace can get from filesystems. It makes little > sense to now add xstat() and not add everything this interface > also exports... The number of flags available will always be a moving target. Better to get the core functionality landed, and then add in new flags in a later patch, otherwise this patch will never be landed. >> The defined bits in request_mask and stx_mask are: >> >> STATX_TYPE Want/got stx_mode & S_IFMT >> STATX_MODE Want/got stx_mode & ~S_IFMT >> STATX_NLINK Want/got stx_nlink >> STATX_UID Want/got stx_uid >> STATX_GID Want/got stx_gid >> STATX_ATIME Want/got stx_atime{,_ns} >> STATX_MTIME Want/got stx_mtime{,_ns} >> STATX_CTIME Want/got stx_ctime{,_ns} >> STATX_INO Want/got stx_ino >> STATX_SIZE Want/got stx_size >> STATX_BLOCKS Want/got stx_blocks >> STATX_BASIC_STATS [The stuff in the normal stat struct] >> STATX_BTIME Want/got stx_btime{,_ns} >> STATX_VERSION Want/got stx_version >> STATX_ALL [All currently available stuff] > > What happens when an application uses STATX_ALL from a future kernel > that defines more flags than are initially supported, and that > application then is run on a kernel that onyl supports the initial > fields? Fields that are unknown by the current kernel/filesystem will not be set, and this is reflected in the flags that are returned to userspace. The minimum required flags are the intersection of the requested flags from userspace and the flags known by the kernel/filesystem. It is possible for the filesystem to optionally return extra flags/fields if they are free to provide, but it should always return the requested flags *if* it knows what those flags mean. >> stx_btime is the file creation time; stx_version is the data version >> number (i_version); stx_mask is a bitmask indicating the data provided; >> and __spares*[] are where as-yet undefined fields can be placed. >> >> Time fields are split into separate seconds and nanoseconds fields to make >> packing easier and the granularities can be queried with the filesystem >> info system call. Note that times will be negative if before 1970; in >> such a case, the nanosecond fields will also be negative if not zero. > > So what happens in ten years time when we want to support > femptosecond resolution in the timestamp interface? We've got to > change everything to 64 bit? Shouldn't we just make everything > timestamp related 64 bit? Is this a serious request? Are we going to need to multiply everything by 10e9 to convert to/from nanoseconds for the next 10 years on the off chance that we have timestamps more accurate than this in the future? We could just as easily add extra 32-bit fields in the future to hold the fraction of nanoseconds if we ever actually need this. Given that we've totally bailed on keeping accurate atimes below a day, I'm not really worried about needing this. >> The bits defined in the stx_attributes field convey information about a >> file, how it is accessed, where it is and what it does. The following >> attributes map to FS_*_FL flags and are the same numerical value: > > Please isolate the new interface flags completely from the FS_*_FL > values. We should not repeat the mistake of tying values derived > from filesystem specific on-disk values to a user interface. Using the existing FS_*_FL flags as initial values is not worse than starting with any other arbitrary values for the flags. >> STATX_ATTR_COMPRESSED File is compressed by the fs >> STATX_ATTR_IMMUTABLE File is marked immutable >> STATX_ATTR_APPEND File is append-only >> STATX_ATTR_NODUMP File is not to be dumped >> STATX_ATTR_ENCRYPTED File requires key to decrypt in fs >> >> The supported flags are listed by: >> >> STATX_ATTR_FS_IOC_FLAGS > > Again, we have many more common and extended flags than this. > NOATIME and SYNC are two that immediately come to mind as generic > flags that should be in this... Sure, and they can be added incrementally in a later patch. I'm not sure why NOATIME and SYNC are missing, and I'm not against adding them, but it is equally likely that they were removed in a previous round of bikeshedding to avoid some real or perceived issue, so that this patch can finally land rather than being in limbo for another 5 years. >> [Are any other IOC flags of sufficient general interest to be exposed >> through this interface?] >> >> New flags include: >> >> STATX_ATTR_NONUNIX_OWNERSHIP File doesn't have Unixy ownership >> STATX_ATTR_HAS_ACL File has an ACL > > So statx will require us to do ACL lookups? i.e. instead of just > reading the inode to get the information, we'll also have to do > extended attribute lookups? That's potentially very expensive if > the extended attribute is not stored in the inode.... No, there is no requirement to return anything that the caller didn't ask for. Only fields that are explicitly requested need to be returned, and others can optionally be returned if it is easy for the filesystem to do so. >> STATX_ATTR_KERNEL_API File is kernel API (eg: procfs/sysfs) >> STATX_ATTR_REMOTE File is remote and needs network >> STATX_ATTR_FABRICATED File was made up by fs > > Every file is fabricated by a filesystem :P > > Perhaps you're wanting "virtual file" because it is has no physical > presence? > >> Fields in struct statx come in a number of classes: >> >> (0) stx_dev_*, stx_blksize. >> >> These are local system information and are always available. > > What does stx_blksize actually mean? It's completely ambiguous in > stat() because we don't actually report the physical block size > here - we report the "minimum unit of efficient IO" that we expect > applications to use. Please define :P > > >> ======= >> TESTING >> ======= >> >> The following test program can be used to test the statx system call: >> >> samples/statx/test-statx.c >> >> Just compile and run, passing it paths to the files you want to examine. >> The file is built automatically if CONFIG_SAMPLES is enabled. > > Can we get xfstests written to exercise and validate all this > functionality, please? I'd suggest that adding xfs_io support for > the statx syscall would be far more useful for xfstests than a > standalone test program, too. We already have equivalent stat() > functionality in xfs_io and that's used quite a bit in xfstests.... > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Andreas [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 3:28 ` Andreas Dilger @ 2016-11-18 22:07 ` Dave Chinner 2016-11-18 22:54 ` David Howells 1 sibling, 0 replies; 52+ messages in thread From: Dave Chinner @ 2016-11-18 22:07 UTC (permalink / raw) To: Andreas Dilger; +Cc: David Howells, linux-fsdevel, linux-kernel On Thu, Nov 17, 2016 at 08:28:57PM -0700, Andreas Dilger wrote: > On Nov 17, 2016, at 4:40 PM, Dave Chinner <david@fromorbit.com> wrote: > >> > >> Time fields are split into separate seconds and nanoseconds fields to make > >> packing easier and the granularities can be queried with the filesystem > >> info system call. Note that times will be negative if before 1970; in > >> such a case, the nanosecond fields will also be negative if not zero. > > > > So what happens in ten years time when we want to support > > femptosecond resolution in the timestamp interface? We've got to > > change everything to 64 bit? Shouldn't we just make everything > > timestamp related 64 bit? > > Is this a serious request? Are we going to need to multiply everything > by 10e9 to convert to/from nanoseconds for the next 10 years on the off > chance that we have timestamps more accurate than this in the future? We've been stuck with the stat() interface since, what, the early 1980s? And it will still be used in 10-15 years time. That's a /50-year lifetime/ for a syscall interface. So it's not unreasonable to think that statx() might have a similar lifetime. statx() is clearly intended to support >y2038 dates cleanly, so clearly we're intending statx() to still be around in 20-25 years. And when we start thinking in those timeframes, an increase in timestamp resoultion of at least another 10e-3 is likely.... > > Please isolate the new interface flags completely from the FS_*_FL > > values. We should not repeat the mistake of tying values derived > > from filesystem specific on-disk values to a user interface. > > Using the existing FS_*_FL flags as initial values is not worse than > starting with any other arbitrary values for the flags. Except it starts with a sparse set of flags for no good reason. Someone comes along needed to add a new flag and wonders WTF there are holes in the flags space, and whether it is because flags have been removed and whether it's unsafe to use the flag space in the holes... New user facing APIs should be clean and neat and not carry any unnecessary historical baggage with them.... > >> STATX_ATTR_NONUNIX_OWNERSHIP File doesn't have Unixy ownership > >> STATX_ATTR_HAS_ACL File has an ACL > > > > So statx will require us to do ACL lookups? i.e. instead of just > > reading the inode to get the information, we'll also have to do > > extended attribute lookups? That's potentially very expensive if > > the extended attribute is not stored in the inode.... > > No, there is no requirement to return anything that the caller didn't > ask for. Applications are going to use STATX_ALL because it's simpler than specifying 10 different flags on every statx() call and then checking them on return. i.e. the set/check feature flags API sounds good until you have to write the boiler plate code it requires time you want to stat a file... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 3:28 ` Andreas Dilger 2016-11-18 22:07 ` Dave Chinner @ 2016-11-18 22:54 ` David Howells 2016-11-19 22:43 ` Dave Chinner ` (2 more replies) 1 sibling, 3 replies; 52+ messages in thread From: David Howells @ 2016-11-18 22:54 UTC (permalink / raw) To: Dave Chinner; +Cc: dhowells, Andreas Dilger, linux-fsdevel, linux-kernel Dave Chinner <david@fromorbit.com> wrote: > And when we start thinking in those timeframes, an > increase in timestamp resoultion of at least another 10e-3 is > likely.... Is it, though? To be useful, surely you have to be able to jam quite a few instructions into a 1ns block, including memory accesses. Rather than providing: struct timestamp { __s64 seconds; __s64 femtoseconds; }; which would require 64-bit divisions to get nanosecond timestamps that we do actually use, I would lean towards: struct timestamp { __s64 seconds; __s32 nanoseconds; __s32 femtoseconds; }; where the fields are, in effect, additive. Which means I could represent this as: __s64 stx_atime_s; /* Last access time */ __s64 stx_btime_s; /* File creation time */ __s64 stx_ctime_s; /* Last attribute change time */ __s64 stx_mtime_s; /* Last data modification time */ __s32 stx_atime_ns; /* Last access time (ns part) */ __s32 stx_btime_ns; /* File creation time (ns part) */ __s32 stx_ctime_ns; /* Last attribute change time (ns part) */ __s32 stx_mtime_ns; /* Last data modification time (ns part) */ and then add: __s32 stx_atime_fs; /* Last access time (fs part) */ __s32 stx_btime_fs; /* File creation time (fs part) */ __s32 stx_ctime_fs; /* Last attribute change time (fs part) */ __s32 stx_mtime_fs; /* Last data modification time (fs part) */ later. If we *really* do want to allow for atto- or femto- second resolution timestamps (and you've still not entirely convinced me that it's going to be necessary - the speed of signal propagation still has an ungetroundable limit), then we could stick the space in now - but I think it's likely to remain dead space. Maybe we should switch to Windows-style timestamp resolution: struct timestamp { __s64 hundred_ns; /* Time in 100ns increments */ __s32 femtoseconds; /* Additional fs component */ }; > > Using the existing FS_*_FL flags as initial values is not worse than > > starting with any other arbitrary values for the flags. > > Except it starts with a sparse set of flags for no good reason. Actually, a very good reason. You can map those flags, on ext4 at least, with a load, an AND and an OR. Three instructions[*]. If the bits don't correspond, it gets more expensive (4-5 instructions per bit + 1). [*] Leastways, it *should* be three instructions, but gcc fails to optimise it correctly. I have a bz logged for this. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 22:54 ` David Howells @ 2016-11-19 22:43 ` Dave Chinner 2016-11-21 14:30 ` One Thousand Gnomes 2016-11-22 10:39 ` David Howells 2 siblings, 0 replies; 52+ messages in thread From: Dave Chinner @ 2016-11-19 22:43 UTC (permalink / raw) To: David Howells; +Cc: Andreas Dilger, linux-fsdevel, linux-kernel On Fri, Nov 18, 2016 at 10:54:02PM +0000, David Howells wrote: > Dave Chinner <david@fromorbit.com> wrote: > > > And when we start thinking in those timeframes, an > > increase in timestamp resoultion of at least another 10e-3 is > > likely.... > > Is it, though? To be useful, surely you have to be able to jam quite a few > instructions into a 1ns block, including memory accesses. > > Rather than providing: > > struct timestamp { > __s64 seconds; > __s64 femtoseconds; > }; > > which would require 64-bit divisions to get nanosecond timestamps that we do > actually use, I would lean towards: > > struct timestamp { > __s64 seconds; > __s32 nanoseconds; > __s32 femtoseconds; > }; No. Just provide a 64 bit high resoultion field, and define it to contain nanoseconds. When we need higher resolution to be exported to userspace, we use a /feature flag/ to indicate that is contains something like attoseconds or the like. This also gives userspace a method of choosing the resolution it wants..... > __s32 stx_btime_ns; /* File creation time (ns part) */ > __s32 stx_ctime_ns; /* Last attribute change time (ns part) */ > __s32 stx_mtime_ns; /* Last data modification time (ns part) */ > > and then add: > > __s32 stx_atime_fs; /* Last access time (fs part) */ > __s32 stx_btime_fs; /* File creation time (fs part) */ > __s32 stx_ctime_fs; /* Last attribute change time (fs part) */ > __s32 stx_mtime_fs; /* Last data modification time (fs part) */ > > later. Which burns a significant part of the spare space in the structure. > If we *really* do want to allow for atto- or femto- second resolution > timestamps (and you've still not entirely convinced me that it's going to be > necessary - the speed of signal propagation still has an ungetroundable > limit), then we could stick the space in now - but I think it's likely to > remain dead space. We don't really care if the strucuture 250 bytes or 300 bytes, it's not going to have any significant impact on memory usage or performance. We should just suck it up now and future proof the timestamp interface, as history has proven repeatedly that we suck as making our time/timestamp interfaces future proof.... > > > Using the existing FS_*_FL flags as initial values is not worse than > > > starting with any other arbitrary values for the flags. > > > > Except it starts with a sparse set of flags for no good reason. > > Actually, a very good reason. You can map those flags, on ext4 at least, with > a load, an AND and an OR. Three instructions[*]. If the bits don't > correspond, it gets more expensive (4-5 instructions per bit + 1). Two words: premature optimisation. Every other filesystem has to map their own internal flags to the user interface flags, so why should we make the user interface harder to understand and maintain just to allow a special snowflake optimisation for /only one filesystem/? There's a worse problem than that, though - we can't add certain flags to the userspace API because the /conflict with ext4 on-disk flags/ that aren't exported to userspace and so to work around that we have this shitty hack to define what parts of the flag space contain flags that the userspace API can interact with: #define FS_FL_USER_VISIBLE 0x0003DFFF /* User visible flags */ #define FS_FL_USER_MODIFIABLE 0x000380FF /* User modifiable flags */ These mask out the ext2/3/4 flags that should not be visible to userspace and/or not be modifiable by userspace. Having to maintain crap like this is a direct result of exporting on-disk flag values to userspace APIs. *Let's not repeat the mistakes of the past* in new interfaces. Cheers, Dave. > > [*] Leastways, it *should* be three instructions, but gcc fails to optimise it > correctly. I have a bz logged for this. > > David > -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 22:54 ` David Howells 2016-11-19 22:43 ` Dave Chinner @ 2016-11-21 14:30 ` One Thousand Gnomes 2016-11-21 20:43 ` Dave Chinner 2016-11-22 10:39 ` David Howells 2 siblings, 1 reply; 52+ messages in thread From: One Thousand Gnomes @ 2016-11-21 14:30 UTC (permalink / raw) To: David Howells; +Cc: Dave Chinner, Andreas Dilger, linux-fsdevel, linux-kernel > > increase in timestamp resoultion of at least another 10e-3 is > > likely.... > > Is it, though? To be useful, surely you have to be able to jam quite a few > instructions into a 1ns block, including memory accesses. > > Rather than providing: > > struct timestamp { > __s64 seconds; > __s64 femtoseconds; > }; > > which would require 64-bit divisions to get nanosecond timestamps that we do > actually use, I would lean towards: > > struct timestamp { > __s64 seconds; > __s32 nanoseconds; > __s32 femtoseconds; > }; Which gets silly. The nanosecond world is defined by the speed of light. Short of someone finding a way to change that digital computing as we know it today is going to be living in the nanoseconds world. You hit the point of 'can't measure the difference' before you hit the point of 'can usefully order things using' Alan ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-21 14:30 ` One Thousand Gnomes @ 2016-11-21 20:43 ` Dave Chinner 0 siblings, 0 replies; 52+ messages in thread From: Dave Chinner @ 2016-11-21 20:43 UTC (permalink / raw) To: One Thousand Gnomes Cc: David Howells, Andreas Dilger, linux-fsdevel, linux-kernel On Mon, Nov 21, 2016 at 02:30:13PM +0000, One Thousand Gnomes wrote: > > > increase in timestamp resoultion of at least another 10e-3 is > > > likely.... > > > > Is it, though? To be useful, surely you have to be able to jam quite a few > > instructions into a 1ns block, including memory accesses. > > > > Rather than providing: > > > > struct timestamp { > > __s64 seconds; > > __s64 femtoseconds; > > }; > > > > which would require 64-bit divisions to get nanosecond timestamps that we do > > actually use, I would lean towards: > > > > struct timestamp { > > __s64 seconds; > > __s32 nanoseconds; > > __s32 femtoseconds; > > }; > > Which gets silly. The nanosecond world is defined by the speed of light. > Short of someone finding a way to change that digital computing as we > know it today is going to be living in the nanoseconds world. You hit the > point of 'can't measure the difference' before you hit the point of 'can > usefully order things using' We already have clock rates that are fractions of a nanosecond per cycle. We have pmem storage here right now that is accessed at the speed of the CPU - actual nanosecond resolution timestamp capability is a reality at the bleeding edge of storage technology right now. It doesn't take much vision to extend the current hardare capabilities with coherent hardware accelerators (e.g. as has been added to the Power platform) writing directly into pmem storage and providing higher resolution timestamps than the CPU can generate. Call me silly if you want - I don't care - but let's not ignore the emerging storage technology trends that are there for everyone to see... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 22:54 ` David Howells 2016-11-19 22:43 ` Dave Chinner 2016-11-21 14:30 ` One Thousand Gnomes @ 2016-11-22 10:39 ` David Howells 2016-11-22 13:55 ` Jeff Layton 2016-11-22 20:58 ` Dave Chinner 2 siblings, 2 replies; 52+ messages in thread From: David Howells @ 2016-11-22 10:39 UTC (permalink / raw) To: Dave Chinner; +Cc: dhowells, Andreas Dilger, linux-fsdevel, linux-kernel Dave Chinner <david@fromorbit.com> wrote: > No. Just provide a 64 bit high resoultion field, and define it to > contain nanoseconds. When we need higher resolution to be exported > to userspace, we use a /feature flag/ to indicate that is contains > something like attoseconds or the like. That sounds suspiciously like a bad idea - if you're talking about a flag with a currently undefined meaning that the kernel can inflict on userspace without warning to change the meaning of the nanoseconds field to something we haven't defined yet. Userspace would have to ask for it. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-22 10:39 ` David Howells @ 2016-11-22 13:55 ` Jeff Layton 2016-11-22 20:58 ` Dave Chinner 1 sibling, 0 replies; 52+ messages in thread From: Jeff Layton @ 2016-11-22 13:55 UTC (permalink / raw) To: David Howells, Dave Chinner; +Cc: Andreas Dilger, linux-fsdevel, linux-kernel On Tue, 2016-11-22 at 10:39 +0000, David Howells wrote: > Dave Chinner <david@fromorbit.com> wrote: > > > > > No. Just provide a 64 bit high resoultion field, and define it to > > contain nanoseconds. When we need higher resolution to be exported > > to userspace, we use a /feature flag/ to indicate that is contains > > something like attoseconds or the like. > > That sounds suspiciously like a bad idea - if you're talking about a flag with > a currently undefined meaning that the kernel can inflict on userspace without > warning to change the meaning of the nanoseconds field to something we haven't > defined yet. > > Userspace would have to ask for it. > Agreed. I think the best thing would be to simply plan to add new femtoseconds fields in the struct if/when it becomes needed. We can easily hide the ugliness of the fields not being adjacent to the rest of the timestamp behind the femtosecond resolution glibc API that will also be needed. If we're worried about space utilization, then let's pad the struct out by 4 extra 32-bit fields in advance of that. Again, a major design point of statx is that it is to be extendable. I don't see any reason that we need to do this now. -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-22 10:39 ` David Howells 2016-11-22 13:55 ` Jeff Layton @ 2016-11-22 20:58 ` Dave Chinner 1 sibling, 0 replies; 52+ messages in thread From: Dave Chinner @ 2016-11-22 20:58 UTC (permalink / raw) To: David Howells; +Cc: Andreas Dilger, linux-fsdevel, linux-kernel On Tue, Nov 22, 2016 at 10:39:29AM +0000, David Howells wrote: > Dave Chinner <david@fromorbit.com> wrote: > > > No. Just provide a 64 bit high resoultion field, and define it to > > contain nanoseconds. When we need higher resolution to be exported > > to userspace, we use a /feature flag/ to indicate that is contains > > something like attoseconds or the like. > > That sounds suspiciously like a bad idea - if you're talking about a flag with > a currently undefined meaning that the kernel can inflict on userspace without > warning to change the meaning of the nanoseconds field to something we haven't > defined yet. > > Userspace would have to ask for it. Yes, of course it would - this would enable userspace to move from struct timespec to something with higher resolution without having to use different structures or guess what the resolution being returned by the kernel is for different filesystems, We had a major mess with the time_t -> struct timespec upgrade of the stat() kernel interface to support nanosecond timestamps in the syscall because when stat() was first designed all those years ago single second resolution was all anyone needed. The original designers of the stat API didn't have 30+ years of history telling them that machines will get faster than anyone could imagine and that timestamps will always get more accurate and increase in resolution. Perhaps people are fine with repeating past mistakes - all I can do is point them out and suggest alternative approaches that will avoid a repeat... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-17 23:40 ` Dave Chinner 2016-11-18 3:28 ` Andreas Dilger @ 2016-11-18 9:53 ` David Howells 1 sibling, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-18 9:53 UTC (permalink / raw) To: Andreas Dilger; +Cc: dhowells, Dave Chinner, linux-fsdevel, linux-kernel Andreas Dilger <adilger@dilger.ca> wrote: > > What happens when an application uses STATX_ALL from a future kernel > > that defines more flags than are initially supported, and that > > application then is run on a kernel that onyl supports the initial > > fields? > > Fields that are unknown by the current kernel/filesystem will not be set, > and this is reflected in the flags that are returned to userspace. Yep. A userspace program can stick 0xffffffff in there if it wants. No error will be incurred. It just won't necessarily get anything back for each of those bits. That said, if we, say, want to reserve bit 31 as a struct extension bit, sticking in 0xffffffff without knowing what this is going to do to you on a kernel that supports a longer struct might give you a problem. But, basically, STATX_ALL indicates what flags have fields in the copy of the struct you got from the header file. There's an extra scenario: you could compile your userspace program against the headers for a particular kernel and then run against a later kernel. In such a case, you may find bits set that are outside STATX_ALL in stx_mask. However, you don't have definitions for those bits and can only ignore them. > > Again, we have many more common and extended flags than this. > > NOATIME and SYNC are two that immediately come to mind as generic > > flags that should be in this... > > Sure, and they can be added incrementally in a later patch. I'm not > sure why NOATIME and SYNC are missing, and I'm not against adding them, > but it is equally likely that they were removed in a previous round of > bikeshedding to avoid some real or perceived issue, so that this patch > can finally land rather than being in limbo for another 5 years. Does it make sense to return them through statx? Note that NOATIME might be considered superfluous given that STATX_ATIME is cleared in such a case. > >> New flags include: > >> > >> STATX_ATTR_NONUNIX_OWNERSHIP File doesn't have Unixy ownership > >> STATX_ATTR_HAS_ACL File has an ACL > > > > So statx will require us to do ACL lookups? i.e. instead of just > > reading the inode to get the information, we'll also have to do > > extended attribute lookups? That's potentially very expensive if > > the extended attribute is not stored in the inode.... > > No, there is no requirement to return anything that the caller didn't > ask for. Only fields that are explicitly requested need to be returned, > and others can optionally be returned if it is easy for the filesystem > to do so. Actually, Dave might have a point. We don't necessarily know that the file has an ACL without doing a getxattr() to probe for it - on the other hand, I would expect the permissions check to have done precisely that. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells 2016-11-17 18:39 ` Jeff Layton 2016-11-17 23:40 ` Dave Chinner @ 2016-11-18 8:48 ` David Howells 2016-11-18 12:01 ` Jeff Layton 2016-11-18 9:36 ` David Howells ` (2 subsequent siblings) 5 siblings, 1 reply; 52+ messages in thread From: David Howells @ 2016-11-18 8:48 UTC (permalink / raw) To: Jeff Layton; +Cc: dhowells, linux-fsdevel, linux-kernel Jeff Layton <jlayton@redhat.com> wrote: > > If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for > > stat() on that filesystem. > > > > We also need to specify here what happens if both bits are set. Should > that be -EINVAL? Makes sense. This leads to another thought: should fstatat() be allowed to take AT_STATX_* flags? David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 8:48 ` David Howells @ 2016-11-18 12:01 ` Jeff Layton 0 siblings, 0 replies; 52+ messages in thread From: Jeff Layton @ 2016-11-18 12:01 UTC (permalink / raw) To: David Howells; +Cc: linux-fsdevel, linux-kernel On Fri, 2016-11-18 at 08:48 +0000, David Howells wrote: > Jeff Layton <jlayton@redhat.com> wrote: > > > > > > > > > If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for > > > stat() on that filesystem. > > > > > > > We also need to specify here what happens if both bits are set. Should > > that be -EINVAL? > > Makes sense. > > This leads to another thought: should fstatat() be allowed to take AT_STATX_* > flags? > > David In principle, we could. fstatat currently rejects flags that it doesn't understand with -EINVAL. That said, I'd vote no -- if you wanted to change an application to start setting these flags in fstatat calls, then it's just as simple to convert it over to use statx. I don't see a lot of benefit in adding that to a legacy syscall. -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells ` (2 preceding siblings ...) 2016-11-18 8:48 ` David Howells @ 2016-11-18 9:36 ` David Howells 2016-11-18 17:17 ` Jeff Layton 2016-11-18 18:04 ` David Howells 2016-11-18 9:43 ` David Howells 2016-11-18 10:29 ` David Howells 5 siblings, 2 replies; 52+ messages in thread From: David Howells @ 2016-11-18 9:36 UTC (permalink / raw) To: Dave Chinner; +Cc: dhowells, linux-fsdevel, linux-kernel Dave Chinner <david@fromorbit.com> wrote: > > (5) Data version number: Could be used by userspace NFS servers [Aneesh > > Kumar]. > > > > Can also be used to modify fill_post_wcc() in NFSD which retrieves > > i_version directly, but has just called vfs_getattr(). It could get > > it from the kstat struct if it used vfs_xgetattr() instead. > > This needs a much clearer name that stx_version as "version" is > entirely ambiguous. e.g. Inodes have internal version numbers to > disambiguate life cycles. and there are versioning filesystems > which have multiple versions of the same file. We've already been through that. I wanted to call it stx_data_version but that got argued down to stx_version. The problem is that what the version number means is entirely filesystem dependent, and it might not just reflect changes in the data. > So if stx_version this is intended to export the internal filesystem > inode change counter (i.e. inode->i_version) then lets call it that: > stx_modification_count. It's clear and unambiguous as to what it > represents, especially as this counter is more than just a "data > modification" counter - inode metadata modifications will also > cause it to change.... I disagree that it's unambiguous. It works like mtime, right? Which wouldn't be of use for certain filesystems. An example of this would be AFS, where it's incremented by 1 each time a write is committed, but is not updated for metadata changes. This is what matters for data caching. > > (13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. > > Note that the Linux IOC flags are a mess and filesystems such as Ext4 > > define flags that aren't in linux/fs.h, so translation in the kernel > > may be a necessity (or, possibly, we provide the filesystem type too). > > And we now also have FS_IOC_FSGETXATTR that extends the flags > and information userspace can get from filesystems. It makes little > sense to now add xstat() and not add everything this interface > also exports... I'm not sure I agree. Stuff like extent sizes and extent hint flags seem like very specialised things that don't belong in the stat interface. The project ID, on the other hand is arguably a good thing to include. But we can always add this later. Note that are also two variants of the fsxattr struct defined in the kernel - though one is a superset of the other. > > Time fields are split into separate seconds and nanoseconds fields to make > > packing easier and the granularities can be queried with the filesystem > > info system call. Note that times will be negative if before 1970; in such > > a case, the nanosecond fields will also be negative if not zero. > > So what happens in ten years time when we want to support > femptosecond resolution in the timestamp interface? We've got to > change everything to 64 bit? Shouldn't we just make everything > timestamp related 64 bit? You really think we're going to have accurate timestamps with a resolution of a millionth of a nanosecond? This means you're going to be doing a 64-bit division every time you want a nanosecond timestamp. Also, violet light has a period of ~1.2fs so your 1fs oscillator might emit UV radiation. > > The bits defined in the stx_attributes field convey information about a > > file, how it is accessed, where it is and what it does. The following > > attributes map to FS_*_FL flags and are the same numerical value: > > Please isolate the new interface flags completely from the FS_*_FL > values. We should not repeat the mistake of tying values derived > from filesystem specific on-disk values to a user interface. Why shouldn't I make a numerical correspondance with at least one set of such flags? I get to define a whole new numberspace and can pick the values I want. I see no particular reason to pick explicitly non-corresponding values where possible. Now, I can agree that the code should say, for example: if (ext4->flag & FS_COMPRESSED_FL) statx.attr |= STATX_ATTR_COMPRESSED; if (ext4->flag & FS_ENCRYPTED_FL) statx.attr |= STATX_ATTR_ENCRYPTED; if (ext4->flag & FS_IMMUTABLE_FL) statx.attr |= STATX_ATTR_IMMUTABLE; ... and that the *compiler* should collapse this to: statx.attr |= ext4->flag & mask; but see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78317 David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 9:36 ` David Howells @ 2016-11-18 17:17 ` Jeff Layton 2016-11-18 18:04 ` David Howells 1 sibling, 0 replies; 52+ messages in thread From: Jeff Layton @ 2016-11-18 17:17 UTC (permalink / raw) To: David Howells, Dave Chinner; +Cc: linux-fsdevel, linux-kernel On Fri, 2016-11-18 at 09:36 +0000, David Howells wrote: > Dave Chinner <david@fromorbit.com> wrote: > > > > (5) Data version number: Could be used by userspace NFS servers [Aneesh > > > Kumar]. > > > > > > Can also be used to modify fill_post_wcc() in NFSD which retrieves > > > i_version directly, but has just called vfs_getattr(). It could get > > > it from the kstat struct if it used vfs_xgetattr() instead. > > > > This needs a much clearer name that stx_version as "version" is > > entirely ambiguous. e.g. Inodes have internal version numbers to > > disambiguate life cycles. and there are versioning filesystems > > which have multiple versions of the same file. > > We've already been through that. I wanted to call it stx_data_version but > that got argued down to stx_version. The problem is that what the version > number means is entirely filesystem dependent, and it might not just reflect > changes in the data. > It had better not just reflect data changes. knfsd populates the NFSv4 change attribute from inode->i_version. It _must_ have changed between subsequent queries if either the data or metadata has changed (basically whenever you would update either the ctime or the mtime). > > So if stx_version this is intended to export the internal filesystem > > inode change counter (i.e. inode->i_version) then lets call it that: > > stx_modification_count. It's clear and unambiguous as to what it > > represents, especially as this counter is more than just a "data > > modification" counter - inode metadata modifications will also > > cause it to change.... > > I disagree that it's unambiguous. It works like mtime, right? > More like ctime + mtime mashed together. > Which wouldn't be of use for certain filesystems. An example of this would be > AFS, where it's incremented by 1 each time a write is committed, but is not > updated for metadata changes. This is what matters for data caching. > No. Basically the rules are that if something in the inode data or metadata changed, then it must be a "larger" value (also accounting for wraparound). So you also need to change it (usually by incrementing it) when doing namespace changes that involve it (renames, unlinks, etc.). > > > (13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. > > > Note that the Linux IOC flags are a mess and filesystems such as Ext4 > > > define flags that aren't in linux/fs.h, so translation in the kernel > > > may be a necessity (or, possibly, we provide the filesystem type too). > > > > And we now also have FS_IOC_FSGETXATTR that extends the flags > > and information userspace can get from filesystems. It makes little > > sense to now add xstat() and not add everything this interface > > also exports... > > I'm not sure I agree. Stuff like extent sizes and extent hint flags seem like > very specialised things that don't belong in the stat interface. The project > ID, on the other hand is arguably a good thing to include. But we can always > add this later. > Yes. The entire point of this interface is that it is extendable. I'm all for simplicity here and just adding the bare minimum of fields to get the new interface in. The main thing we must do here though is to ID anything that would hobble us from being able to add new attributes later. Adding new fields in later piecemeal patches allows us to demonstrate that that concept actually works. > Note that are also two variants of the fsxattr struct defined in the kernel - > though one is a superset of the other. > > > > Time fields are split into separate seconds and nanoseconds fields to make > > > packing easier and the granularities can be queried with the filesystem > > > info system call. Note that times will be negative if before 1970; in such > > > a case, the nanosecond fields will also be negative if not zero. > > > > So what happens in ten years time when we want to support > > femptosecond resolution in the timestamp interface? We've got to > > change everything to 64 bit? Shouldn't we just make everything > > timestamp related 64 bit? > > You really think we're going to have accurate timestamps with a resolution of > a millionth of a nanosecond? This means you're going to be doing a 64-bit > division every time you want a nanosecond timestamp. > > Also, violet light has a period of ~1.2fs so your 1fs oscillator might emit UV > radiation. > Could contemporary machines get away with just shifting down by 32 bits? > > > The bits defined in the stx_attributes field convey information about a > > > file, how it is accessed, where it is and what it does. The following > > > attributes map to FS_*_FL flags and are the same numerical value: > > > > Please isolate the new interface flags completely from the FS_*_FL > > values. We should not repeat the mistake of tying values derived > > from filesystem specific on-disk values to a user interface. > > Why shouldn't I make a numerical correspondance with at least one set of such > flags? I get to define a whole new numberspace and can pick the values I > want. I see no particular reason to pick explicitly non-corresponding values > where possible. > > Now, I can agree that the code should say, for example: > > if (ext4->flag & FS_COMPRESSED_FL) > statx.attr |= STATX_ATTR_COMPRESSED; > if (ext4->flag & FS_ENCRYPTED_FL) > statx.attr |= STATX_ATTR_ENCRYPTED; > if (ext4->flag & FS_IMMUTABLE_FL) > statx.attr |= STATX_ATTR_IMMUTABLE; > ... > > and that the *compiler* should collapse this to: > > statx.attr |= ext4->flag & mask; > > but see: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78317 > > David > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 9:36 ` David Howells 2016-11-18 17:17 ` Jeff Layton @ 2016-11-18 18:04 ` David Howells 2016-11-18 18:54 ` Jeff Layton 2016-11-18 19:08 ` David Howells 1 sibling, 2 replies; 52+ messages in thread From: David Howells @ 2016-11-18 18:04 UTC (permalink / raw) To: Jeff Layton; +Cc: dhowells, Dave Chinner, linux-fsdevel, linux-kernel Jeff Layton <jlayton@poochiereds.net> wrote: > > We've already been through that. I wanted to call it stx_data_version but > > that got argued down to stx_version. The problem is that what the version > > number means is entirely filesystem dependent, and it might not just reflect > > changes in the data. > > > > It had better not just reflect data changes. > > knfsd populates the NFSv4 change attribute from inode->i_version. It > _must_ have changed between subsequent queries if either the data or > metadata has changed (basically whenever you would update either the > ctime or the mtime). No, I think it *should* just reflect the data changes - otherwise you have have to burn your cached data unnecessarily. > > > So if stx_version this is intended to export the internal filesystem > > > inode change counter (i.e. inode->i_version) then lets call it that: > > > stx_modification_count. It's clear and unambiguous as to what it > > > represents, especially as this counter is more than just a "data > > > modification" counter - inode metadata modifications will also > > > cause it to change.... > > > > I disagree that it's unambiguous. It works like mtime, right? > > More like ctime + mtime mashed together. Isn't ctime updated every time mtime is? In which case stx_change_count would be a better name. > > Which wouldn't be of use for certain filesystems. An example of this > > would be AFS, where it's incremented by 1 each time a write is committed, > > but is not updated for metadata changes. This is what matters for data > > caching. > > > > No. Basically the rules are that if something in the inode data or > metadata changed, then it must be a "larger" value (also accounting for > wraparound). So you also need to change it (usually by incrementing it) > when doing namespace changes that involve it (renames, unlinks, etc.). That's entirely filesystem dependent. A better rule is that if you do a write and then compare the data version you got back to the version you had before; if it's increased by exactly one, there were no other writes between your last retrieval of the attributes and your write that just got committed. Admittedly, this assumes that the server serialises writes to a particular file. If the value just increases, you don't know that didn't happen by this mechanism, so the version is of limited value. > Adding new fields in later piecemeal patches allows us to demonstrate > that that concept actually works. You're probably right, but the downside is that we really need some way to find out what's supported. On the other hand, we probably need that anyway, hence my suggestion of an fsinfo() syscall also. > > You really think we're going to have accurate timestamps with a resolution > > of a millionth of a nanosecond? This means you're going to be doing a > > 64-bit division every time you want a nanosecond timestamp. > ... > > Could contemporary machines get away with just shifting down by 32 > bits? A better way would probably be to have: struct timestamp { __u64 seconds; __u32 nanoseconds; __u32 femtoseconds; }; where you effectively add all the fields together with appropriate multipliers. But I still wonder if we really are going to move to femtosecond timestamps, given that that's going to involve clock frequencies well in excess of 1 THz to be useful. Even attoseconds is probably unnecessary, given that clock frequencies don't seem to be moving much beyond a few GHz, though it's reasonable that we could have a timestamp counter that has an attosecond period - it's just that the processing time to deal with it seems likely to render it unnecessary. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 18:04 ` David Howells @ 2016-11-18 18:54 ` Jeff Layton 2016-11-18 19:08 ` David Howells 1 sibling, 0 replies; 52+ messages in thread From: Jeff Layton @ 2016-11-18 18:54 UTC (permalink / raw) To: David Howells; +Cc: Dave Chinner, linux-fsdevel, linux-kernel On Fri, 2016-11-18 at 18:04 +0000, David Howells wrote: > Jeff Layton <jlayton@poochiereds.net> wrote: > > > > We've already been through that. I wanted to call it stx_data_version but > > > that got argued down to stx_version. The problem is that what the version > > > number means is entirely filesystem dependent, and it might not just reflect > > > changes in the data. > > > > > > > It had better not just reflect data changes. > > > > knfsd populates the NFSv4 change attribute from inode->i_version. It > > _must_ have changed between subsequent queries if either the data or > > metadata has changed (basically whenever you would update either the > > ctime or the mtime). > > No, I think it *should* just reflect the data changes - otherwise you have > have to burn your cached data unnecessarily. > > > > > So if stx_version this is intended to export the internal filesystem > > > > inode change counter (i.e. inode->i_version) then lets call it that: > > > > stx_modification_count. It's clear and unambiguous as to what it > > > > represents, especially as this counter is more than just a "data > > > > modification" counter - inode metadata modifications will also > > > > cause it to change.... > > > > > > I disagree that it's unambiguous. It works like mtime, right? > > > > More like ctime + mtime mashed together. > > Isn't ctime updated every time mtime is? In which case stx_change_count would > be a better name. > > > > Which wouldn't be of use for certain filesystems. An example of this > > > would be AFS, where it's incremented by 1 each time a write is committed, > > > but is not updated for metadata changes. This is what matters for data > > > caching. > > > > > > > No. Basically the rules are that if something in the inode data or > > metadata changed, then it must be a "larger" value (also accounting for > > wraparound). So you also need to change it (usually by incrementing it) > > when doing namespace changes that involve it (renames, unlinks, etc.). > > That's entirely filesystem dependent. > My mistake. I had thought that i_version was only used for NFSv4, and a few internal callers (particularly, some readdir implementations). I didn't realize that AFS also uses it. > A better rule is that if you do a write and then compare the data version you > got back to the version you had before; if it's increased by exactly one, > there were no other writes between your last retrieval of the attributes and > your write that just got committed. Admittedly, this assumes that the server > serialises writes to a particular file. > > If the value just increases, you don't know that didn't happen by this > mechanism, so the version is of limited value. > For the case of NFSv4, you can't infer that anyway. The protocol pretty much states that the client has to treat this value as semi-opaque. It can't infer anything other than "something has changed" (though it can look to see if a change attribute is "old" and discard it). Does AFS allow you to infer something from the actual value? Now that I realize that AFS has very different semantics, we might want to step back for a bit on presenting i_version to userspace. I think we need to come to some agreement on what i_version should actually mean before we expose it to userland to use. Maybe we should consider separate stx_change_attr and stx_data_change_attr fields in here? > > Adding new fields in later piecemeal patches allows us to demonstrate > > that that concept actually works. > > You're probably right, but the downside is that we really need some way to > find out what's supported. On the other hand, we probably need that anyway, > hence my suggestion of an fsinfo() syscall also. > Yeah, I think we will need an fsinfo call of some sort eventually. Alternately, we could just add the fields of interest to statx so that the callers can just query for it with the other fields (e.g. STATX_TS_GRANULARITY). Just document those attributes as being per- mount or whatever. > > > You really think we're going to have accurate timestamps with a resolution > > > of a millionth of a nanosecond? This means you're going to be doing a > > > 64-bit division every time you want a nanosecond timestamp. > > > > ... > > > > Could contemporary machines get away with just shifting down by 32 > > bits? > > A better way would probably be to have: > > struct timestamp { > __u64 seconds; > __u32 nanoseconds; > __u32 femtoseconds; > }; > > where you effectively add all the fields together with appropriate > multipliers. > Harder for those femtosecond scale machines to deal with, but maybe you're right. If the plan is to do that then we can just punt that out until that need arises, and add stx_?time_fsec fields at that point. The ugliness would all be hidden behind the glibc wrapper anyway (in principle). > But I still wonder if we really are going to move to femtosecond timestamps, > given that that's going to involve clock frequencies well in excess of 1 THz > to be useful. Even attoseconds is probably unnecessary, given that clock > frequencies don't seem to be moving much beyond a few GHz, though it's > reasonable that we could have a timestamp counter that has an attosecond > period - it's just that the processing time to deal with it seems likely to > render it unnecessary. > > David True, and we have to figure here that these are _file_ times, so you'd have to have file updates happening on sub-nanosecond timescales for this to make sense as well. I don't think we really need to add this now, especially if we can add the extra fields if/when the need ever arises. -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 18:04 ` David Howells 2016-11-18 18:54 ` Jeff Layton @ 2016-11-18 19:08 ` David Howells 1 sibling, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-18 19:08 UTC (permalink / raw) To: Jeff Layton; +Cc: dhowells, Dave Chinner, linux-fsdevel, linux-kernel Jeff Layton <jlayton@redhat.com> wrote: > Does AFS allow you to infer something from the actual value? Yes. Given: (1) Each write on a file is atomic with respect to all other writes to that same file. (2) The data version is incremented by exactly one for each write committed, and that value is returned in the reply to the write RPC call. If you think you have a file with version 99, you do a call and get back version 100, you *know* that there was no conflicting write before your write. If the version came back as 101, however, you *know* that there was a write you didn't know about. Therefore, you have to flush your cache. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells ` (3 preceding siblings ...) 2016-11-18 9:36 ` David Howells @ 2016-11-18 9:43 ` David Howells 2016-11-18 21:41 ` Dave Chinner 2016-11-18 22:24 ` David Howells 2016-11-18 10:29 ` David Howells 5 siblings, 2 replies; 52+ messages in thread From: David Howells @ 2016-11-18 9:43 UTC (permalink / raw) To: Dave Chinner; +Cc: dhowells, linux-fsdevel, linux-kernel Dave Chinner <david@fromorbit.com> wrote: > > STATX_ATTR_KERNEL_API File is kernel API (eg: procfs/sysfs) > > STATX_ATTR_REMOTE File is remote and needs network > > STATX_ATTR_FABRICATED File was made up by fs > > Every file is fabricated by a filesystem :P > > Perhaps you're wanting "virtual file" because it is has no physical > presence? Yeah - that might be a better name. The idea of FABRICATED is to note objects that have no actual existence in the backing store. Directories that had to be invented to act as mountpoints would be a good example of this. > > Fields in struct statx come in a number of classes: > > > > (0) stx_dev_*, stx_blksize. > > > > These are local system information and are always available. > > What does stx_blksize actually mean? It's completely ambiguous in > stat() because we don't actually report the physical block size > here - we report the "minimum unit of efficient IO" that we expect > applications to use. Please define :P Definition: "Same as struct stat::st_blksize". > > The following test program can be used to test the statx system call: > > > > samples/statx/test-statx.c > > > > Just compile and run, passing it paths to the files you want to examine. > > The file is built automatically if CONFIG_SAMPLES is enabled. > > Can we get xfstests written to exercise and validate all this > functionality, please? I'd suggest that adding xfs_io support for > the statx syscall would be far more useful for xfstests than a > standalone test program, too. We already have equivalent stat() > functionality in xfs_io and that's used quite a bit in xfstests.... Feel free to write some! ;-) But I need a simple standalone test program to be able to test what I write, and I've no inclination to wheel out huge testsuites for an interface that people are still arguing about and wanting changed. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 9:43 ` David Howells @ 2016-11-18 21:41 ` Dave Chinner 2016-11-18 22:24 ` David Howells 1 sibling, 0 replies; 52+ messages in thread From: Dave Chinner @ 2016-11-18 21:41 UTC (permalink / raw) To: David Howells; +Cc: linux-fsdevel, linux-kernel On Fri, Nov 18, 2016 at 09:43:38AM +0000, David Howells wrote: > Dave Chinner <david@fromorbit.com> wrote: > > > Fields in struct statx come in a number of classes: > > > > > > (0) stx_dev_*, stx_blksize. > > > > > > These are local system information and are always available. > > > > What does stx_blksize actually mean? It's completely ambiguous in > > stat() because we don't actually report the physical block size > > here - we report the "minimum unit of efficient IO" that we expect > > applications to use. Please define :P > > Definition: "Same as struct stat::st_blksize". So it is still defined as "mostly useless", then? :/ > > > The following test program can be used to test the statx system call: > > > > > > samples/statx/test-statx.c > > > > > > Just compile and run, passing it paths to the files you want to examine. > > > The file is built automatically if CONFIG_SAMPLES is enabled. > > > > Can we get xfstests written to exercise and validate all this > > functionality, please? I'd suggest that adding xfs_io support for > > the statx syscall would be far more useful for xfstests than a > > standalone test program, too. We already have equivalent stat() > > functionality in xfs_io and that's used quite a bit in xfstests.... > > Feel free to write some! ;-) No, not my job. It is the responsibility of the person added new functionality to write the validity tests for everyone else to use. > But I need a simple standalone test program to be able to test what I write, > and I've no inclination to wheel out huge testsuites for an interface that > people are still arguing about and wanting changed. The test suite should be developed concurrently with the code. You know, best software engineering practices and all that. Just a small example: Darrick landed 100+ reflink related tests in xfstests before we merged the XFS reflink functionality. And that's just for XFS - this is something that /all filesystems/ need to work correctly with, so it's even more important that we have tests to verify functionality /before/ it gets merged. Quite frankly, I think this has to be an unconditional requirement for such generic, expandabled new syscall functionality - either we get test coverage for it before merge, or we don't merge it. We've demonstrated time and time again that shit doesn't work if it's not tested and cannot be widely verified by independent filesystem developers. Again, I'll use the example of Darrick's reflink tests - that exposed multiple bugs in the btrfs reflink implementation that nobody knew existed because /they'd never been tested/. And we've found several subtle differences in fs implementations that would seriously confuse applications (e.g. how a range of "0 bytes" is treated by the filesystem) as a result of adding tests to exercise these exact semantics. These are the sorts of issues we need test coverage to avoid, and we need it before merge, not after. Cheers, Dave. > > David > -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 9:43 ` David Howells 2016-11-18 21:41 ` Dave Chinner @ 2016-11-18 22:24 ` David Howells 1 sibling, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-18 22:24 UTC (permalink / raw) To: Dave Chinner; +Cc: dhowells, linux-fsdevel, linux-kernel Dave Chinner <david@fromorbit.com> wrote: > > Definition: "Same as struct stat::st_blksize". > > So it is still defined as "mostly useless", then? :/ If we're going to be able to emulate stat() with this, then st_blksize must be determinable from whatever's in struct statx. If you can provide something better for stx_blksize and an algorithm for mapping that to st_blksize, then please do so. > The test suite should be developed concurrently with the code. You > know, best software engineering practices and all that. Just a small > example: Darrick landed 100+ reflink related tests in xfstests > before we merged the XFS reflink functionality. I can't give you tests to merge yet. Given the amount of bikeshedding that's taken place on this, I'm glad I *haven't* done the testsuite yet - it would have much more than doubled the amount of work. I *still* don't know what the final form is going to be. I've chucked out almost everything extra because every bit has someone who argues with it - and this includes people who argue against things that have to be there! Further: warthog>ls xfstests-dev/doc CHANGES The documentation is missing. There's a bit in the top level README, but there's a whole lot of information that *should* be there - and isn't. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells @ 2016-11-18 10:29 ` David Howells 2016-11-17 23:40 ` Dave Chinner ` (4 subsequent siblings) 5 siblings, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-18 10:29 UTC (permalink / raw) To: Dave Chinner; +Cc: dhowells, linux-fsdevel, linux-kernel, linux-api Dave Chinner <david@fromorbit.com> wrote: > > (13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. > > Note that the Linux IOC flags are a mess and filesystems such as Ext4 > > define flags that aren't in linux/fs.h, so translation in the kernel > > may be a necessity (or, possibly, we provide the filesystem type too). > > And we now also have FS_IOC_FSGETXATTR that extends the flags > and information userspace can get from filesystems. Btw, can you point me at the manpage that defines the fsxattr struct and its flags? Also, ioctl_list(2) should probably include FS_IOC_FS[GS]ETXATTR. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available @ 2016-11-18 10:29 ` David Howells 0 siblings, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-18 10:29 UTC (permalink / raw) To: Dave Chinner Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org> wrote: > > (13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. > > Note that the Linux IOC flags are a mess and filesystems such as Ext4 > > define flags that aren't in linux/fs.h, so translation in the kernel > > may be a necessity (or, possibly, we provide the filesystem type too). > > And we now also have FS_IOC_FSGETXATTR that extends the flags > and information userspace can get from filesystems. Btw, can you point me at the manpage that defines the fsxattr struct and its flags? Also, ioctl_list(2) should probably include FS_IOC_FS[GS]ETXATTR. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 10:29 ` David Howells (?) @ 2016-11-18 21:27 ` Dave Chinner -1 siblings, 0 replies; 52+ messages in thread From: Dave Chinner @ 2016-11-18 21:27 UTC (permalink / raw) To: David Howells; +Cc: linux-fsdevel, linux-kernel, linux-api On Fri, Nov 18, 2016 at 10:29:04AM +0000, David Howells wrote: > Dave Chinner <david@fromorbit.com> wrote: > > > > (13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. > > > Note that the Linux IOC flags are a mess and filesystems such as Ext4 > > > define flags that aren't in linux/fs.h, so translation in the kernel > > > may be a necessity (or, possibly, we provide the filesystem type too). > > > > And we now also have FS_IOC_FSGETXATTR that extends the flags > > and information userspace can get from filesystems. > > Btw, can you point me at the manpage that defines the fsxattr struct and its > flags? man xfsctl is the original source. However, .... > Also, ioctl_list(2) should probably include FS_IOC_FS[GS]ETXATTR. ... I thought patches had been sent to Michael to document them at the VFS ioctl level. maybe I confused it with something else..... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 10:29 ` David Howells @ 2016-11-18 21:48 ` David Howells -1 siblings, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-18 21:48 UTC (permalink / raw) To: Dave Chinner; +Cc: dhowells, linux-fsdevel, linux-kernel, linux-api Dave Chinner <david@fromorbit.com> wrote: > > Btw, can you point me at the manpage that defines the fsxattr struct and its > > flags? > > man xfsctl is the original source. However, .... warthog>man xfsctl No manual entry for xfsctl This should be in the kernel manpages repo since it's kernel UAPI. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available @ 2016-11-18 21:48 ` David Howells 0 siblings, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-18 21:48 UTC (permalink / raw) To: Dave Chinner Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org> wrote: > > Btw, can you point me at the manpage that defines the fsxattr struct and its > > flags? > > man xfsctl is the original source. However, .... warthog>man xfsctl No manual entry for xfsctl This should be in the kernel manpages repo since it's kernel UAPI. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available @ 2016-11-18 22:17 ` Dave Chinner 0 siblings, 0 replies; 52+ messages in thread From: Dave Chinner @ 2016-11-18 22:17 UTC (permalink / raw) To: David Howells; +Cc: linux-fsdevel, linux-kernel, linux-api On Fri, Nov 18, 2016 at 09:48:21PM +0000, David Howells wrote: > Dave Chinner <david@fromorbit.com> wrote: > > > > Btw, can you point me at the manpage that defines the fsxattr struct and its > > > flags? > > > > man xfsctl is the original source. However, .... > > warthog>man xfsctl > No manual entry for xfsctl > > This should be in the kernel manpages repo since it's kernel UAPI. "original source" is where the API came from - that's XFS_IOC_FSGETXATTR - and xfsctl from xfsprogs is where that was documented. That page documents a bunch of other XFS specific ioctls, too, so it is appropriately located. Like I said, I thought patches had been sent to Michael to lift the FS_IOC_FSGETXATTR documentation from this page into the official linux man pages package. If not, that can be chased up separately, but the XFS ioctl man page certainly does not belong there. Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available @ 2016-11-18 22:17 ` Dave Chinner 0 siblings, 0 replies; 52+ messages in thread From: Dave Chinner @ 2016-11-18 22:17 UTC (permalink / raw) To: David Howells Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA On Fri, Nov 18, 2016 at 09:48:21PM +0000, David Howells wrote: > Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org> wrote: > > > > Btw, can you point me at the manpage that defines the fsxattr struct and its > > > flags? > > > > man xfsctl is the original source. However, .... > > warthog>man xfsctl > No manual entry for xfsctl > > This should be in the kernel manpages repo since it's kernel UAPI. "original source" is where the API came from - that's XFS_IOC_FSGETXATTR - and xfsctl from xfsprogs is where that was documented. That page documents a bunch of other XFS specific ioctls, too, so it is appropriately located. Like I said, I thought patches had been sent to Michael to lift the FS_IOC_FSGETXATTR documentation from this page into the official linux man pages package. If not, that can be chased up separately, but the XFS ioctl man page certainly does not belong there. Cheers, Dave. -- Dave Chinner david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available 2016-11-18 22:17 ` Dave Chinner (?) @ 2016-11-19 10:21 ` Michael Kerrisk (man-pages) -1 siblings, 0 replies; 52+ messages in thread From: Michael Kerrisk (man-pages) @ 2016-11-19 10:21 UTC (permalink / raw) To: Dave Chinner; +Cc: David Howells, linux-fsdevel, lkml, Linux API, Li Xi Hi Dave, [Best to CC me when I'm mentioned in the discussion. I only caught this by chance.] On 18 November 2016 at 23:17, Dave Chinner <david@fromorbit.com> wrote: > On Fri, Nov 18, 2016 at 09:48:21PM +0000, David Howells wrote: >> Dave Chinner <david@fromorbit.com> wrote: >> >> > > Btw, can you point me at the manpage that defines the fsxattr struct and its >> > > flags? >> > >> > man xfsctl is the original source. However, .... >> >> warthog>man xfsctl >> No manual entry for xfsctl >> >> This should be in the kernel manpages repo since it's kernel UAPI. > > "original source" is where the API came from - that's > XFS_IOC_FSGETXATTR - and xfsctl from xfsprogs is where that was > documented. That page documents a bunch of other XFS specific > ioctls, too, so it is appropriately located. > > Like I said, I thought patches had been sent to Michael to lift the > FS_IOC_FSGETXATTR documentation from this page into the official > linux man pages package. If not, that can be chased up separately, > but the XFS ioctl man page certainly does not belong there. No patches for FS_IOC_FSGETXATTR documentation came to man-pages, as far as I know. I'll be happy to take them. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 2/4] statx: Ext4: Return enhanced file attributes 2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells 2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells @ 2016-11-17 13:35 ` David Howells 2016-11-18 3:30 ` Andreas Dilger 2016-11-17 13:35 ` [PATCH 3/4] statx: NFS: " David Howells ` (5 subsequent siblings) 7 siblings, 1 reply; 52+ messages in thread From: David Howells @ 2016-11-17 13:35 UTC (permalink / raw) To: linux-fsdevel; +Cc: dhowells, linux-kernel Return enhanced file attributes from the Ext4 filesystem. This includes the following: (1) The inode creation time (i_crtime) as stx_btime, setting STATX_BTIME. (2) The inode i_version as stx_version if a file with I_VERSION set or a directory, setting STATX_VERSION. (3) Certain FS_xxx_FL flags are copied to stx_attribute flags. This requires that all ext4 inodes have a getattr call, not just some of them, so to this end, split the ext4_getattr() function and only call part of it where appropriate. Example output: [root@andromeda ~]# touch foo [root@andromeda ~]# chattr +ai foo [root@andromeda ~]# /tmp/test-statx foo statx(foo) = 0 results=fff Size: 0 Blocks: 0 IO Block: 4096 regular file Device: 08:12 Inode: 2101950 Links: 1 Access: (0644/-rw-r--r--) Uid: 0 Gid: 0 Access: 2016-02-11 17:08:29.031795451+0000 Modify: 2016-02-11 17:08:29.031795451+0000 Change: 2016-02-11 17:11:11.987790114+0000 Birth: 2016-02-11 17:08:29.031795451+0000 Attributes: 0000000000000030 (-------- -------- -------- -------- -------- -------- -------- --ai----) IO-blocksize: blksize=4096 Signed-off-by: David Howells <dhowells@redhat.com> --- fs/ext4/ext4.h | 2 ++ fs/ext4/file.c | 2 +- fs/ext4/inode.c | 38 +++++++++++++++++++++++++++++++++++--- fs/ext4/namei.c | 2 ++ fs/ext4/symlink.c | 2 ++ 5 files changed, 42 insertions(+), 4 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 282a51b07c57..f65e4a560c4c 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -2485,6 +2485,8 @@ extern int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat); extern void ext4_evict_inode(struct inode *); extern void ext4_clear_inode(struct inode *); +extern int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry, + struct kstat *stat); extern int ext4_sync_inode(handle_t *, struct inode *); extern void ext4_dirty_inode(struct inode *, int); extern int ext4_change_inode_journal_flag(struct inode *, int); diff --git a/fs/ext4/file.c b/fs/ext4/file.c index 2a822d30e73f..20bab4b0d6fc 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -705,7 +705,7 @@ const struct file_operations ext4_file_operations = { const struct inode_operations ext4_file_inode_operations = { .setattr = ext4_setattr, - .getattr = ext4_getattr, + .getattr = ext4_file_getattr, .listxattr = ext4_listxattr, .get_acl = ext4_get_acl, .set_acl = ext4_set_acl, diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 9c064727ed62..91a49cbc4c63 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -5229,11 +5229,43 @@ int ext4_setattr(struct dentry *dentry, struct iattr *attr) int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) { - struct inode *inode; - unsigned long long delalloc_blocks; + struct inode *inode = d_inode(dentry); + struct ext4_inode *raw_inode; + struct ext4_inode_info *ei = EXT4_I(inode); + unsigned int flags; + + if (EXT4_FITS_IN_INODE(raw_inode, ei, i_crtime)) { + stat->result_mask |= STATX_BTIME; + stat->btime.tv_sec = ei->i_crtime.tv_sec; + stat->btime.tv_nsec = ei->i_crtime.tv_nsec; + } + + if (S_ISDIR(inode->i_mode) || IS_I_VERSION(inode)) { + stat->result_mask |= STATX_VERSION; + stat->version = inode->i_version; + } + + ext4_get_inode_flags(ei); + flags = ei->i_flags & EXT4_FL_USER_VISIBLE; + stat->attributes |= flags & (EXT4_IMMUTABLE_FL | EXT4_NODUMP_FL); + if (flags & EXT4_APPEND_FL) + stat->attributes |= STATX_ATTR_APPEND; + if (flags & EXT4_COMPR_FL) + stat->attributes |= STATX_ATTR_COMPRESSED; + if (flags & EXT4_ENCRYPT_FL) + stat->attributes |= STATX_ATTR_ENCRYPTED; - inode = d_inode(dentry); generic_fillattr(inode, stat); + return 0; +} + +int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry, + struct kstat *stat) +{ + struct inode *inode = dentry->d_inode; + u64 delalloc_blocks; + + ext4_getattr(mnt, dentry, stat); /* * If there is inline data in the inode, the inode will normally not diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 104f8bfba718..e115281fb8c5 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -3882,6 +3882,7 @@ const struct inode_operations ext4_dir_inode_operations = { .tmpfile = ext4_tmpfile, .rename = ext4_rename2, .setattr = ext4_setattr, + .getattr = ext4_getattr, .listxattr = ext4_listxattr, .get_acl = ext4_get_acl, .set_acl = ext4_set_acl, @@ -3890,6 +3891,7 @@ const struct inode_operations ext4_dir_inode_operations = { const struct inode_operations ext4_special_inode_operations = { .setattr = ext4_setattr, + .getattr = ext4_getattr, .listxattr = ext4_listxattr, .get_acl = ext4_get_acl, .set_acl = ext4_set_acl, diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c index 557b3b0d668c..209b833633e2 100644 --- a/fs/ext4/symlink.c +++ b/fs/ext4/symlink.c @@ -93,6 +93,7 @@ const struct inode_operations ext4_symlink_inode_operations = { .readlink = generic_readlink, .get_link = page_get_link, .setattr = ext4_setattr, + .getattr = ext4_getattr, .listxattr = ext4_listxattr, }; @@ -100,5 +101,6 @@ const struct inode_operations ext4_fast_symlink_inode_operations = { .readlink = generic_readlink, .get_link = simple_get_link, .setattr = ext4_setattr, + .getattr = ext4_getattr, .listxattr = ext4_listxattr, }; ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH 2/4] statx: Ext4: Return enhanced file attributes 2016-11-17 13:35 ` [PATCH 2/4] statx: Ext4: Return enhanced file attributes David Howells @ 2016-11-18 3:30 ` Andreas Dilger 0 siblings, 0 replies; 52+ messages in thread From: Andreas Dilger @ 2016-11-18 3:30 UTC (permalink / raw) To: David Howells; +Cc: linux-fsdevel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 6168 bytes --] On Nov 17, 2016, at 6:35 AM, David Howells <dhowells@redhat.com> wrote: > > Return enhanced file attributes from the Ext4 filesystem. This includes > the following: > > (1) The inode creation time (i_crtime) as stx_btime, setting STATX_BTIME. > > (2) The inode i_version as stx_version if a file with I_VERSION set or a > directory, setting STATX_VERSION. > > (3) Certain FS_xxx_FL flags are copied to stx_attribute flags. > > > This requires that all ext4 inodes have a getattr call, not just some of > them, so to this end, split the ext4_getattr() function and only call part > of it where appropriate. > > Example output: > > [root@andromeda ~]# touch foo > [root@andromeda ~]# chattr +ai foo > [root@andromeda ~]# /tmp/test-statx foo > statx(foo) = 0 > results=fff > Size: 0 Blocks: 0 IO Block: 4096 regular file > Device: 08:12 Inode: 2101950 Links: 1 > Access: (0644/-rw-r--r--) Uid: 0 Gid: 0 > Access: 2016-02-11 17:08:29.031795451+0000 > Modify: 2016-02-11 17:08:29.031795451+0000 > Change: 2016-02-11 17:11:11.987790114+0000 > Birth: 2016-02-11 17:08:29.031795451+0000 > Attributes: 0000000000000030 (-------- -------- -------- -------- -------- -------- -------- --ai----) > IO-blocksize: blksize=4096 > > Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Andreas Dilger <adilger@dilger.ca> > --- > > fs/ext4/ext4.h | 2 ++ > fs/ext4/file.c | 2 +- > fs/ext4/inode.c | 38 +++++++++++++++++++++++++++++++++++--- > fs/ext4/namei.c | 2 ++ > fs/ext4/symlink.c | 2 ++ > 5 files changed, 42 insertions(+), 4 deletions(-) > > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h > index 282a51b07c57..f65e4a560c4c 100644 > --- a/fs/ext4/ext4.h > +++ b/fs/ext4/ext4.h > @@ -2485,6 +2485,8 @@ extern int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry, > struct kstat *stat); > extern void ext4_evict_inode(struct inode *); > extern void ext4_clear_inode(struct inode *); > +extern int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry, > + struct kstat *stat); > extern int ext4_sync_inode(handle_t *, struct inode *); > extern void ext4_dirty_inode(struct inode *, int); > extern int ext4_change_inode_journal_flag(struct inode *, int); > diff --git a/fs/ext4/file.c b/fs/ext4/file.c > index 2a822d30e73f..20bab4b0d6fc 100644 > --- a/fs/ext4/file.c > +++ b/fs/ext4/file.c > @@ -705,7 +705,7 @@ const struct file_operations ext4_file_operations = { > > const struct inode_operations ext4_file_inode_operations = { > .setattr = ext4_setattr, > - .getattr = ext4_getattr, > + .getattr = ext4_file_getattr, > .listxattr = ext4_listxattr, > .get_acl = ext4_get_acl, > .set_acl = ext4_set_acl, > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c > index 9c064727ed62..91a49cbc4c63 100644 > --- a/fs/ext4/inode.c > +++ b/fs/ext4/inode.c > @@ -5229,11 +5229,43 @@ int ext4_setattr(struct dentry *dentry, struct iattr *attr) > int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry, > struct kstat *stat) > { > - struct inode *inode; > - unsigned long long delalloc_blocks; > + struct inode *inode = d_inode(dentry); > + struct ext4_inode *raw_inode; > + struct ext4_inode_info *ei = EXT4_I(inode); > + unsigned int flags; > + > + if (EXT4_FITS_IN_INODE(raw_inode, ei, i_crtime)) { > + stat->result_mask |= STATX_BTIME; > + stat->btime.tv_sec = ei->i_crtime.tv_sec; > + stat->btime.tv_nsec = ei->i_crtime.tv_nsec; > + } > + > + if (S_ISDIR(inode->i_mode) || IS_I_VERSION(inode)) { > + stat->result_mask |= STATX_VERSION; > + stat->version = inode->i_version; > + } > + > + ext4_get_inode_flags(ei); > + flags = ei->i_flags & EXT4_FL_USER_VISIBLE; > + stat->attributes |= flags & (EXT4_IMMUTABLE_FL | EXT4_NODUMP_FL); > + if (flags & EXT4_APPEND_FL) > + stat->attributes |= STATX_ATTR_APPEND; > + if (flags & EXT4_COMPR_FL) > + stat->attributes |= STATX_ATTR_COMPRESSED; > + if (flags & EXT4_ENCRYPT_FL) > + stat->attributes |= STATX_ATTR_ENCRYPTED; > > - inode = d_inode(dentry); > generic_fillattr(inode, stat); > + return 0; > +} > + > +int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry, > + struct kstat *stat) > +{ > + struct inode *inode = dentry->d_inode; > + u64 delalloc_blocks; > + > + ext4_getattr(mnt, dentry, stat); > > /* > * If there is inline data in the inode, the inode will normally not > diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c > index 104f8bfba718..e115281fb8c5 100644 > --- a/fs/ext4/namei.c > +++ b/fs/ext4/namei.c > @@ -3882,6 +3882,7 @@ const struct inode_operations ext4_dir_inode_operations = { > .tmpfile = ext4_tmpfile, > .rename = ext4_rename2, > .setattr = ext4_setattr, > + .getattr = ext4_getattr, > .listxattr = ext4_listxattr, > .get_acl = ext4_get_acl, > .set_acl = ext4_set_acl, > @@ -3890,6 +3891,7 @@ const struct inode_operations ext4_dir_inode_operations = { > > const struct inode_operations ext4_special_inode_operations = { > .setattr = ext4_setattr, > + .getattr = ext4_getattr, > .listxattr = ext4_listxattr, > .get_acl = ext4_get_acl, > .set_acl = ext4_set_acl, > diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c > index 557b3b0d668c..209b833633e2 100644 > --- a/fs/ext4/symlink.c > +++ b/fs/ext4/symlink.c > @@ -93,6 +93,7 @@ const struct inode_operations ext4_symlink_inode_operations = { > .readlink = generic_readlink, > .get_link = page_get_link, > .setattr = ext4_setattr, > + .getattr = ext4_getattr, > .listxattr = ext4_listxattr, > }; > > @@ -100,5 +101,6 @@ const struct inode_operations ext4_fast_symlink_inode_operations = { > .readlink = generic_readlink, > .get_link = simple_get_link, > .setattr = ext4_setattr, > + .getattr = ext4_getattr, > .listxattr = ext4_listxattr, > }; > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Andreas [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 3/4] statx: NFS: Return enhanced file attributes 2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells 2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells 2016-11-17 13:35 ` [PATCH 2/4] statx: Ext4: Return enhanced file attributes David Howells @ 2016-11-17 13:35 ` David Howells 2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells ` (4 subsequent siblings) 7 siblings, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-17 13:35 UTC (permalink / raw) To: linux-fsdevel; +Cc: dhowells, linux-kernel Return enhanced file atrributes from the NFS filesystem. This includes the following: (1) The change attribute as stx_version if NFSv4. (2) STATX_ATTR_AUTOMOUNT and STATX_ATTR_FABRICATED are set on referral or submount directories that are automounted upon. NFS shows one directory with a different FSID, but the local VFS has two: the mountpoint directory (fabricated) and the root of the filesystem mounted upon it. (3) STATX_ATTR_REMOTE is set on files acquired over NFS. Furthermore, what nfs_getattr() does can be controlled as follows: (1) If AT_STATX_DONT_SYNC is indicated then this will suppress the flushing of outstanding writes and the rereading of the inode's attributes with the server as detailed below. (2) Otherwise: (a) If AT_STATX_FORCE_SYNC is indicated, or mtime, ctime or data_version (NFSv4 only) are requested then the outstanding writes will be written to the server first. (b) The inode's attributes will be reread from the server: (i) if AT_STATX_FORCE_SYNC is indicated; (ii) if atime is requested (and atime updating is not suppressed by a mount flag); or (iii) if the cached attributes have expired; If the inode isn't synchronised, then the cached attributes will be used - even if expired - without reference to the server. Example output: [root@andromeda ~]# ./samples/statx/test-statx /warthog/ statx(/warthog/) = 0 results=17ff Size: 4096 Blocks: 8 IO Block: 1048576 directory Device: 00:26 Inode: 2 Links: 21 Access: (0555/dr-xr-xr-x) Uid: 0 Gid: 0 Access: 2016-11-14 11:49:14.582749262+0000 Modify: 2016-09-08 20:39:46.785788707+0100 Change: 2016-09-08 20:39:46.785788707+0100 Data version: 57d1be822ed62f23h Attributes: 0000000000002000 (-------- -------- -------- -------- -------- -------- --r----- --------) IO-blocksize: blksize=1048576 Note that the NFS4 protocol potentially provides a creation time that could be passed through this interface and system, hidden and archive values that could be passed as attributes. There is also a backup time that could be exposed. Signed-off-by: David Howells <dhowells@redhat.com> --- fs/nfs/inode.c | 41 ++++++++++++++++++++++++++++++++++------- 1 file changed, 34 insertions(+), 7 deletions(-) diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c index bf4ec5ecc97e..73c4502d4abb 100644 --- a/fs/nfs/inode.c +++ b/fs/nfs/inode.c @@ -656,12 +656,23 @@ static bool nfs_need_revalidate_inode(struct inode *inode) int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) { struct inode *inode = d_inode(dentry); - int need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME; + bool force_sync = stat->query_flags & AT_STATX_FORCE_SYNC; + bool suppress_sync = stat->query_flags & AT_STATX_DONT_SYNC; + bool need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME; int err = 0; trace_nfs_getattr_enter(inode); - /* Flush out writes to the server in order to update c/mtime. */ - if (S_ISREG(inode->i_mode)) { + + if (NFS_SERVER(inode)->nfs_client->rpc_ops->version < 4) + stat->request_mask &= ~STATX_VERSION; + + /* Flush out writes to the server in order to update c/mtime or data + * version if the user wants them. + */ + if (S_ISREG(inode->i_mode) && !suppress_sync && + (force_sync || (stat->request_mask & + (STATX_MTIME | STATX_CTIME | STATX_VERSION))) + ) { err = filemap_write_and_wait(inode->i_mapping); if (err) goto out; @@ -676,11 +687,13 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) * - NFS never sets MS_NOATIME or MS_NODIRATIME so there is * no point in checking those. */ - if ((mnt->mnt_flags & MNT_NOATIME) || - ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode))) - need_atime = 0; + if (!(stat->request_mask & STATX_ATIME) || + (mnt->mnt_flags & MNT_NOATIME) || + ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode))) + need_atime = false; - if (need_atime || nfs_need_revalidate_inode(inode)) { + if (!suppress_sync && + (force_sync || need_atime || nfs_need_revalidate_inode(inode))) { struct nfs_server *server = NFS_SERVER(inode); if (server->caps & NFS_CAP_READDIRPLUS) @@ -693,6 +706,20 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) if (S_ISDIR(inode->i_mode)) stat->blksize = NFS_SERVER(inode)->dtsize; } + + generic_fillattr(inode, stat); + stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode)); + + if (stat->request_mask & STATX_VERSION) { + stat->version = inode->i_version; + stat->result_mask |= STATX_VERSION; + } + + if (IS_AUTOMOUNT(inode)) + stat->attributes |= STATX_ATTR_FABRICATED; + + stat->attributes |= STATX_ATTR_REMOTE; + out: trace_nfs_getattr_exit(inode, err); return err; ^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH 4/4] statx: AFS: Return enhanced file attributes 2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells ` (2 preceding siblings ...) 2016-11-17 13:35 ` [PATCH 3/4] statx: NFS: " David Howells @ 2016-11-17 13:35 ` David Howells 2016-11-18 3:34 ` Andreas Dilger 2016-11-18 8:47 ` David Howells 2016-11-17 14:39 ` [RFC][PATCH 0/4] Enhanced file stat system call One Thousand Gnomes ` (3 subsequent siblings) 7 siblings, 2 replies; 52+ messages in thread From: David Howells @ 2016-11-17 13:35 UTC (permalink / raw) To: linux-fsdevel; +Cc: dhowells, linux-kernel Return enhanced file attributes from the AFS filesystem. This includes the following: (1) The data version number as st_version, setting STATX_VERSION. (2) STATX_ATTR_AUTOMOUNT will be set on automount directories by virtue of S_AUTOMOUNT being set on the inode. These are referrals to other volumes or other cells. (3) STATX_ATTR_UNLISTED_DENTS on a directory that does cell lookup for non-existent names and mounts them (typically mounted on /afs with -o autocell). The resulting directories are marked STATX_ATTR_FABRICATED as they do not actually exist in the mounted AFS directory. (4) Files, directories and symlinks accessed over AFS are marked STATX_ATTR_REMOTE. STATX_ATIME, STATX_CTIME and STATX_BLOCKS are cleared as AFS does not support them. Example output: [root@andromeda ~]# ./samples/statx/test-statx /afs statx(/afs) = 0 results=7ef Size: 2048 Blocks: 0 IO Block: 4096 directory Device: 00:25 Inode: 1 Links: 2 Access: (0777/drwxrwxrwx) Uid: 0 Gid: 0 Access: 2006-05-07 00:21:15.000000000+0100 Modify: 2006-05-07 00:21:15.000000000+0100 Change: 2006-05-07 00:21:15.000000000+0100 IO-blocksize: blksize=4096 Signed-off-by: David Howells <dhowells@redhat.com> --- fs/afs/inode.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/fs/afs/inode.c b/fs/afs/inode.c index 86cc7264c21c..b08c405a7e1b 100644 --- a/fs/afs/inode.c +++ b/fs/afs/inode.c @@ -72,9 +72,9 @@ static int afs_inode_map_status(struct afs_vnode *vnode, struct key *key) inode->i_uid = vnode->status.owner; inode->i_gid = GLOBAL_ROOT_GID; inode->i_size = vnode->status.size; - inode->i_ctime.tv_sec = vnode->status.mtime_server; - inode->i_ctime.tv_nsec = 0; - inode->i_atime = inode->i_mtime = inode->i_ctime; + inode->i_mtime.tv_sec = vnode->status.mtime_server; + inode->i_mtime.tv_nsec = 0; + inode->i_atime = inode->i_ctime = inode->i_mtime; inode->i_blocks = 0; inode->i_generation = vnode->fid.unique; inode->i_version = vnode->status.data_version; @@ -375,8 +375,7 @@ int afs_validate(struct afs_vnode *vnode, struct key *key) /* * read the attributes of an inode */ -int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, - struct kstat *stat) +int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) { struct inode *inode; @@ -385,6 +384,18 @@ int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, _enter("{ ino=%lu v=%u }", inode->i_ino, inode->i_generation); generic_fillattr(inode, stat); + + stat->result_mask &= ~(STATX_ATIME | STATX_CTIME | STATX_BLOCKS); + stat->result_mask |= STATX_VERSION; + stat->version = inode->i_version; + + if (test_bit(AFS_VNODE_AUTOCELL, &AFS_FS_I(inode)->flags)) + stat->attributes |= STATX_ATTR_UNLISTED_DENTS; + + if (test_bit(AFS_VNODE_PSEUDODIR, &AFS_FS_I(inode)->flags)) + stat->attributes |= STATX_ATTR_FABRICATED; + else + stat->attributes |= STATX_ATTR_REMOTE; return 0; } ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH 4/4] statx: AFS: Return enhanced file attributes 2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells @ 2016-11-18 3:34 ` Andreas Dilger 2016-11-18 8:47 ` David Howells 1 sibling, 0 replies; 52+ messages in thread From: Andreas Dilger @ 2016-11-18 3:34 UTC (permalink / raw) To: David Howells; +Cc: linux-fsdevel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 3907 bytes --] On Nov 17, 2016, at 6:35 AM, David Howells <dhowells@redhat.com> wrote: > > Return enhanced file attributes from the AFS filesystem. This includes the > following: > > (1) The data version number as st_version, setting STATX_VERSION. > > (2) STATX_ATTR_AUTOMOUNT will be set on automount directories by virtue of > S_AUTOMOUNT being set on the inode. These are referrals to other > volumes or other cells. > > (3) STATX_ATTR_UNLISTED_DENTS on a directory that does cell lookup for > non-existent names and mounts them (typically mounted on /afs with -o > autocell). The resulting directories are marked STATX_ATTR_FABRICATED > as they do not actually exist in the mounted AFS directory. > > (4) Files, directories and symlinks accessed over AFS are marked > STATX_ATTR_REMOTE. > > STATX_ATIME, STATX_CTIME and STATX_BLOCKS are cleared as AFS does not > support them. Rather than clearing specific flags, wouldn't it be better to explicitly set the flags that are actually being returned? Otherwise, this would have the problem that Dave pointed out on the 0/4 patch, that there may be flags still set from userspace that do not mean anything to AFS. Cheers, Andreas > > Example output: > > [root@andromeda ~]# ./samples/statx/test-statx /afs > statx(/afs) = 0 > results=7ef > Size: 2048 Blocks: 0 IO Block: 4096 directory > Device: 00:25 Inode: 1 Links: 2 > Access: (0777/drwxrwxrwx) Uid: 0 Gid: 0 > Access: 2006-05-07 00:21:15.000000000+0100 > Modify: 2006-05-07 00:21:15.000000000+0100 > Change: 2006-05-07 00:21:15.000000000+0100 > IO-blocksize: blksize=4096 > > Signed-off-by: David Howells <dhowells@redhat.com> > --- > > fs/afs/inode.c | 21 ++++++++++++++++----- > 1 file changed, 16 insertions(+), 5 deletions(-) > > diff --git a/fs/afs/inode.c b/fs/afs/inode.c > index 86cc7264c21c..b08c405a7e1b 100644 > --- a/fs/afs/inode.c > +++ b/fs/afs/inode.c > @@ -72,9 +72,9 @@ static int afs_inode_map_status(struct afs_vnode *vnode, struct key *key) > inode->i_uid = vnode->status.owner; > inode->i_gid = GLOBAL_ROOT_GID; > inode->i_size = vnode->status.size; > - inode->i_ctime.tv_sec = vnode->status.mtime_server; > - inode->i_ctime.tv_nsec = 0; > - inode->i_atime = inode->i_mtime = inode->i_ctime; > + inode->i_mtime.tv_sec = vnode->status.mtime_server; > + inode->i_mtime.tv_nsec = 0; > + inode->i_atime = inode->i_ctime = inode->i_mtime; > inode->i_blocks = 0; > inode->i_generation = vnode->fid.unique; > inode->i_version = vnode->status.data_version; > @@ -375,8 +375,7 @@ int afs_validate(struct afs_vnode *vnode, struct key *key) > /* > * read the attributes of an inode > */ > -int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, > - struct kstat *stat) > +int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) > { > struct inode *inode; > > @@ -385,6 +384,18 @@ int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, > _enter("{ ino=%lu v=%u }", inode->i_ino, inode->i_generation); > > generic_fillattr(inode, stat); > + > + stat->result_mask &= ~(STATX_ATIME | STATX_CTIME | STATX_BLOCKS); > + stat->result_mask |= STATX_VERSION; > + stat->version = inode->i_version; > + > + if (test_bit(AFS_VNODE_AUTOCELL, &AFS_FS_I(inode)->flags)) > + stat->attributes |= STATX_ATTR_UNLISTED_DENTS; > + > + if (test_bit(AFS_VNODE_PSEUDODIR, &AFS_FS_I(inode)->flags)) > + stat->attributes |= STATX_ATTR_FABRICATED; > + else > + stat->attributes |= STATX_ATTR_REMOTE; > return 0; > } > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Andreas [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 4/4] statx: AFS: Return enhanced file attributes 2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells 2016-11-18 3:34 ` Andreas Dilger @ 2016-11-18 8:47 ` David Howells 1 sibling, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-18 8:47 UTC (permalink / raw) To: Andreas Dilger; +Cc: dhowells, linux-fsdevel, linux-kernel Andreas Dilger <adilger@dilger.ca> wrote: > > STATX_ATIME, STATX_CTIME and STATX_BLOCKS are cleared as AFS does not > > support them. > > Rather than clearing specific flags, wouldn't it be better to explicitly > set the flags that are actually being returned? Otherwise, this would > have the problem that Dave pointed out on the 0/4 patch, that there may > be flags still set from userspace that do not mean anything to AFS. I'm not sure it make a difference. generic_fillattr() has to initialise result_mask to STATX_BASIC_STATS for the support of any unmodified filesystem. We can then either clear the bits we don't want or just overwrite the mask entirely with the bits we do want. Bits in request_mask that are beyond STATX_BASIC_STATS are not automatically propagated to result_mask. Possibly vfs_xgetattr_nosec() should preset the result_mask rather than doing this in generic_fillattr(). David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC][PATCH 0/4] Enhanced file stat system call 2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells ` (3 preceding siblings ...) 2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells @ 2016-11-17 14:39 ` One Thousand Gnomes 2016-11-17 15:10 ` Michael Kerrisk ` (2 subsequent siblings) 7 siblings, 0 replies; 52+ messages in thread From: One Thousand Gnomes @ 2016-11-17 14:39 UTC (permalink / raw) To: David Howells; +Cc: linux-fsdevel, linux-kernel > (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of > interest, and allow a network fs to approximate anything not of > interest, without going to the server. > > (3) Heavyweight stat (AT_STATX_FORCE_SYNC): Force a network fs to flush > buffers and go to the server, even if it thinks its cached attributes > are up to date. That seems an odd way to do it. Wouldn't it be cleaner and more flexible to give a timestamp of the oldest time you consider acceptable (and obviously passing 0 indicates whatever you have) > (4) Allow the filesystem to indicate what it can/cannot provide: A > filesystem can now say it doesn't support a standard stat feature if > that isn't available. > > (5) Make the fields a consistent size on all arches, and make them large. > > (6) Can be extended by using more request flags and using up the padding > space in the statx struct. > > Note that no lstat() equivalent is required as that can be implemented > through statx() with atflag == 0. There is also no fstat() equivalent as > that can be implemented through statx() with filename == NULL and the > relevant fd passed as dfd. and dfd + a name gives you fstatat() ? The cover note could be clearer on this. Should the fields really be split the way they are for times rather than a struct for each one so you can write code generically to handle one of those rather than having to have a 4 way switch statement all the time. Another attribute that would be nice (but migt need some trivial device layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will probably evaporate on a reboot. That's useful information for tools like installers and also for sanity checking things like backup paths. Remote needs to have clear semantics: is ext4fs over nbd 'remote' for example ? Alan ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC][PATCH 0/4] Enhanced file stat system call 2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells ` (4 preceding siblings ...) 2016-11-17 14:39 ` [RFC][PATCH 0/4] Enhanced file stat system call One Thousand Gnomes @ 2016-11-17 15:10 ` Michael Kerrisk 2016-11-17 16:33 ` David Howells 2016-11-17 16:45 ` David Howells 7 siblings, 0 replies; 52+ messages in thread From: Michael Kerrisk @ 2016-11-17 15:10 UTC (permalink / raw) To: David Howells; +Cc: Linux-Fsdevel, Linux Kernel, Linux API Hi David, Can you please CC linux-api@ on all future iterations of this patch! Thanks, Michael On Thu, Nov 17, 2016 at 2:34 PM, David Howells <dhowells@redhat.com> wrote: > > Implement a new system call to provide enhanced file stats. The patches can > be found here: > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat > > > =========== > DESCRIPTION > =========== > > The first patch provides this new system call: > > long ret = statx(int dfd, > const char *filename, > unsigned atflag, > unsigned mask, > struct statx *buffer); > > This is an enhanced file stat function that provides a number of useful > features, in summary: > > (1) More information: creation time, data version number and attributes. > A subset of these is available through a number of filesystems (such > as CIFS, NFS, AFS, Ext4 and BTRFS). > > (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of > interest, and allow a network fs to approximate anything not of > interest, without going to the server. > > (3) Heavyweight stat (AT_STATX_FORCE_SYNC): Force a network fs to flush > buffers and go to the server, even if it thinks its cached attributes > are up to date. > > (4) Allow the filesystem to indicate what it can/cannot provide: A > filesystem can now say it doesn't support a standard stat feature if > that isn't available. > > (5) Make the fields a consistent size on all arches, and make them large. > > (6) Can be extended by using more request flags and using up the padding > space in the statx struct. > > Note that no lstat() equivalent is required as that can be implemented > through statx() with atflag == 0. There is also no fstat() equivalent as > that can be implemented through statx() with filename == NULL and the > relevant fd passed as dfd. > > > ======= > TESTING > ======= > > A test program is added into samples/statx/ by the first patch. > > David > --- > David Howells (4): > statx: Add a system call to make enhanced file info available > statx: Ext4: Return enhanced file attributes > statx: NFS: Return enhanced file attributes > statx: AFS: Return enhanced file attributes > > > arch/x86/entry/syscalls/syscall_32.tbl | 1 > arch/x86/entry/syscalls/syscall_64.tbl | 1 > fs/afs/inode.c | 21 ++ > fs/exportfs/expfs.c | 4 > fs/ext4/ext4.h | 2 > fs/ext4/file.c | 2 > fs/ext4/inode.c | 38 ++++ > fs/ext4/namei.c | 2 > fs/ext4/symlink.c | 2 > fs/nfs/inode.c | 41 ++++ > fs/stat.c | 294 +++++++++++++++++++++++++++++--- > include/linux/fs.h | 5 - > include/linux/stat.h | 19 +- > include/linux/syscalls.h | 3 > include/uapi/linux/fcntl.h | 2 > include/uapi/linux/stat.h | 124 +++++++++++++ > samples/Kconfig | 5 + > samples/Makefile | 3 > samples/statx/Makefile | 10 + > samples/statx/test-statx.c | 248 +++++++++++++++++++++++++++ > 20 files changed, 771 insertions(+), 56 deletions(-) > create mode 100644 samples/statx/Makefile > create mode 100644 samples/statx/test-statx.c > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface", http://blog.man7.org/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC][PATCH 0/4] Enhanced file stat system call 2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells ` (5 preceding siblings ...) 2016-11-17 15:10 ` Michael Kerrisk @ 2016-11-17 16:33 ` David Howells 2016-11-17 16:45 ` David Howells 7 siblings, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-17 16:33 UTC (permalink / raw) To: Michael Kerrisk; +Cc: dhowells, Linux-Fsdevel, Linux Kernel, Linux API Michael Kerrisk <mtk.manpages@gmail.com> wrote: > Can you please CC linux-api@ on all future iterations of this patch! Sorry, yes - I remembered right after posting it, of course. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC][PATCH 0/4] Enhanced file stat system call 2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells ` (6 preceding siblings ...) 2016-11-17 16:33 ` David Howells @ 2016-11-17 16:45 ` David Howells 2016-11-17 20:00 ` J. Bruce Fields ` (2 more replies) 7 siblings, 3 replies; 52+ messages in thread From: David Howells @ 2016-11-17 16:45 UTC (permalink / raw) To: One Thousand Gnomes; +Cc: dhowells, linux-fsdevel, linux-kernel One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote: > > (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of > > interest, and allow a network fs to approximate anything not of > > interest, without going to the server. > > > > (3) Heavyweight stat (AT_STATX_FORCE_SYNC): Force a network fs to flush > > buffers and go to the server, even if it thinks its cached attributes > > are up to date. > > That seems an odd way to do it. Wouldn't it be cleaner and more flexible > to give a timestamp of the oldest time you consider acceptable (and > obviously passing 0 indicates whatever you have) Perhaps, though adding 6-argument syscalls is apparently frowned upon. > > Note that no lstat() equivalent is required as that can be implemented > > through statx() with atflag == 0. There is also no fstat() equivalent as > > that can be implemented through statx() with filename == NULL and the > > relevant fd passed as dfd. > > and dfd + a name gives you fstatat() ? Yes. > The cover note could be clearer on this. Fixed. > Should the fields really be split the way they are for times rather than > a struct for each one so you can write code generically to handle one of > those rather than having to have a 4 way switch statement all the time. It depends. Doing so leaves 16 bytes of hole in the structure. I could ameliorate the wastage by using a union to overlay useful fields in the gaps, but that's pretty icky and might be compiler dependent. > Another attribute that would be nice (but migt need some trivial device > layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will > probably evaporate on a reboot. That's useful information for tools like > installers and also for sanity checking things like backup paths. There's a FILE_ATTRIBUTE_TEMPORARY that I could map for windows filesystems that could be used with this. > Remote needs to have clear semantics: is ext4fs over nbd 'remote' for > example ? Hmmm... Interesting question. Probably should. But you could be insane and RAID an nbd and a local disk. Further, does NFS over a loopback device to nfsd on the same machine qualify as root? What if that's exposing a local fs on NBD? Perhaps I should drop 'REMOTE' for now. It sounds like something that a GUI filemanager might find interesting, though. David ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC][PATCH 0/4] Enhanced file stat system call 2016-11-17 16:45 ` David Howells @ 2016-11-17 20:00 ` J. Bruce Fields 2016-11-18 2:30 ` Andreas Dilger 2016-11-18 13:41 ` One Thousand Gnomes 2016-11-18 13:49 ` David Howells 2 siblings, 1 reply; 52+ messages in thread From: J. Bruce Fields @ 2016-11-17 20:00 UTC (permalink / raw) To: David Howells; +Cc: One Thousand Gnomes, linux-fsdevel, linux-kernel On Thu, Nov 17, 2016 at 04:45:45PM +0000, David Howells wrote: > One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote: > > > > (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of > > > interest, and allow a network fs to approximate anything not of > > > interest, without going to the server. > > > > > > (3) Heavyweight stat (AT_STATX_FORCE_SYNC): Force a network fs to flush > > > buffers and go to the server, even if it thinks its cached attributes > > > are up to date. > > > > That seems an odd way to do it. Wouldn't it be cleaner and more flexible > > to give a timestamp of the oldest time you consider acceptable (and > > obviously passing 0 indicates whatever you have) > > Perhaps, though adding 6-argument syscalls is apparently frowned upon. > > > > Note that no lstat() equivalent is required as that can be implemented > > > through statx() with atflag == 0. There is also no fstat() equivalent as > > > that can be implemented through statx() with filename == NULL and the > > > relevant fd passed as dfd. > > > > and dfd + a name gives you fstatat() ? > > Yes. > > > The cover note could be clearer on this. > > Fixed. > > > Should the fields really be split the way they are for times rather than > > a struct for each one so you can write code generically to handle one of > > those rather than having to have a 4 way switch statement all the time. > > It depends. Doing so leaves 16 bytes of hole in the structure. I could > ameliorate the wastage by using a union to overlay useful fields in the gaps, > but that's pretty icky and might be compiler dependent. > > > Another attribute that would be nice (but migt need some trivial device > > layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will > > probably evaporate on a reboot. That's useful information for tools like > > installers and also for sanity checking things like backup paths. > > There's a FILE_ATTRIBUTE_TEMPORARY that I could map for windows filesystems > that could be used with this. > > > Remote needs to have clear semantics: is ext4fs over nbd 'remote' for > > example ? > > Hmmm... Interesting question. Probably should. But you could be insane and > RAID an nbd and a local disk. Further, does NFS over a loopback device to > nfsd on the same machine qualify as root? What if that's exposing a local fs > on NBD? Perhaps I should drop 'REMOTE' for now. It sounds like something > that a GUI filemanager might find interesting, though. Sorry, I haven't been paying attention, just popping up for this, but: "shared" might be a more useful term than "remote". A filesystem that may be mounted from more than one system is "shared". Caching performance and semantics of such a filesystem are more complicated since the filesystem may change out from under us. This is what makes e.g. the lightweight/heavyweight stat difference more interesting in the shared case. The filesystem should be able to make that shared/unshared distinction without knowledge of the storage it's sitting on top of. Answering your questions by that criterion: - ext4/nbd: not shared - nfs/lo: shared But, it's fine with me to drop any features for now as long as we can always add them later. --b. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC][PATCH 0/4] Enhanced file stat system call 2016-11-17 20:00 ` J. Bruce Fields @ 2016-11-18 2:30 ` Andreas Dilger 2016-11-18 4:29 ` NeilBrown 0 siblings, 1 reply; 52+ messages in thread From: Andreas Dilger @ 2016-11-18 2:30 UTC (permalink / raw) To: J. Bruce Fields Cc: David Howells, One Thousand Gnomes, linux-fsdevel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 3696 bytes --] > On Nov 17, 2016, at 1:00 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > > On Thu, Nov 17, 2016 at 04:45:45PM +0000, David Howells wrote: >> One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote: >> >>>> (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of >>>> interest, and allow a network fs to approximate anything not of >>>> interest, without going to the server. >>>> >>>> (3) Heavyweight stat (AT_STATX_FORCE_SYNC): Force a network fs to flush >>>> buffers and go to the server, even if it thinks its cached attributes >>>> are up to date. >>> >>> That seems an odd way to do it. Wouldn't it be cleaner and more flexible >>> to give a timestamp of the oldest time you consider acceptable (and >>> obviously passing 0 indicates whatever you have) >> >> Perhaps, though adding 6-argument syscalls is apparently frowned upon. >> >>>> Note that no lstat() equivalent is required as that can be implemented >>>> through statx() with atflag == 0. There is also no fstat() equivalent as >>>> that can be implemented through statx() with filename == NULL and the >>>> relevant fd passed as dfd. >>> >>> and dfd + a name gives you fstatat() ? >> >> Yes. >> >>> The cover note could be clearer on this. >> >> Fixed. >> >>> Should the fields really be split the way they are for times rather than >>> a struct for each one so you can write code generically to handle one of >>> those rather than having to have a 4 way switch statement all the time. >> >> It depends. Doing so leaves 16 bytes of hole in the structure. I could >> ameliorate the wastage by using a union to overlay useful fields in the gaps, >> but that's pretty icky and might be compiler dependent. >> >>> Another attribute that would be nice (but migt need some trivial device >>> layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will >>> probably evaporate on a reboot. That's useful information for tools like >>> installers and also for sanity checking things like backup paths. >> >> There's a FILE_ATTRIBUTE_TEMPORARY that I could map for windows filesystems >> that could be used with this. >> >>> Remote needs to have clear semantics: is ext4fs over nbd 'remote' for >>> example ? >> >> Hmmm... Interesting question. Probably should. But you could be insane and >> RAID an nbd and a local disk. Further, does NFS over a loopback device to >> nfsd on the same machine qualify as root? What if that's exposing a local fs >> on NBD? Perhaps I should drop 'REMOTE' for now. It sounds like something >> that a GUI filemanager might find interesting, though. > > Sorry, I haven't been paying attention, just popping up for this, but: > "shared" might be a more useful term than "remote". > > A filesystem that may be mounted from more than one system is "shared". > Caching performance and semantics of such a filesystem are more > complicated since the filesystem may change out from under us. This is > what makes e.g. the lightweight/heavyweight stat difference more > interesting in the shared case. > > The filesystem should be able to make that shared/unshared distinction > without knowledge of the storage it's sitting on top of. > > Answering your questions by that criterion: > > - ext4/nbd: not shared > - nfs/lo: shared > > But, it's fine with me to drop any features for now as long as we can > always add them later. Please, please, please, let's get the syscall and basic functionality landed first, and then nit-pick about extensions later. This has been dragging on for _years_ and bike shedded to death. Cheers, Andreas [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC][PATCH 0/4] Enhanced file stat system call 2016-11-18 2:30 ` Andreas Dilger @ 2016-11-18 4:29 ` NeilBrown 0 siblings, 0 replies; 52+ messages in thread From: NeilBrown @ 2016-11-18 4:29 UTC (permalink / raw) To: Andreas Dilger, J. Bruce Fields Cc: David Howells, One Thousand Gnomes, linux-fsdevel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 4499 bytes --] On Fri, Nov 18 2016, Andreas Dilger wrote: > [ Unknown signature status ] > >> On Nov 17, 2016, at 1:00 PM, J. Bruce Fields <bfields@fieldses.org> wrote: >> >> On Thu, Nov 17, 2016 at 04:45:45PM +0000, David Howells wrote: >>> One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote: >>> >>>>> (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of >>>>> interest, and allow a network fs to approximate anything not of >>>>> interest, without going to the server. >>>>> >>>>> (3) Heavyweight stat (AT_STATX_FORCE_SYNC): Force a network fs to flush >>>>> buffers and go to the server, even if it thinks its cached attributes >>>>> are up to date. >>>> >>>> That seems an odd way to do it. Wouldn't it be cleaner and more flexible >>>> to give a timestamp of the oldest time you consider acceptable (and >>>> obviously passing 0 indicates whatever you have) >>> >>> Perhaps, though adding 6-argument syscalls is apparently frowned upon. >>> >>>>> Note that no lstat() equivalent is required as that can be implemented >>>>> through statx() with atflag == 0. There is also no fstat() equivalent as >>>>> that can be implemented through statx() with filename == NULL and the >>>>> relevant fd passed as dfd. >>>> >>>> and dfd + a name gives you fstatat() ? >>> >>> Yes. >>> >>>> The cover note could be clearer on this. >>> >>> Fixed. >>> >>>> Should the fields really be split the way they are for times rather than >>>> a struct for each one so you can write code generically to handle one of >>>> those rather than having to have a 4 way switch statement all the time. >>> >>> It depends. Doing so leaves 16 bytes of hole in the structure. I could >>> ameliorate the wastage by using a union to overlay useful fields in the gaps, >>> but that's pretty icky and might be compiler dependent. >>> >>>> Another attribute that would be nice (but migt need some trivial device >>>> layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will >>>> probably evaporate on a reboot. That's useful information for tools like >>>> installers and also for sanity checking things like backup paths. >>> >>> There's a FILE_ATTRIBUTE_TEMPORARY that I could map for windows filesystems >>> that could be used with this. >>> >>>> Remote needs to have clear semantics: is ext4fs over nbd 'remote' for >>>> example ? >>> >>> Hmmm... Interesting question. Probably should. But you could be insane and >>> RAID an nbd and a local disk. Further, does NFS over a loopback device to >>> nfsd on the same machine qualify as root? What if that's exposing a local fs >>> on NBD? Perhaps I should drop 'REMOTE' for now. It sounds like something >>> that a GUI filemanager might find interesting, though. >> >> Sorry, I haven't been paying attention, just popping up for this, but: >> "shared" might be a more useful term than "remote". >> >> A filesystem that may be mounted from more than one system is "shared". >> Caching performance and semantics of such a filesystem are more >> complicated since the filesystem may change out from under us. This is >> what makes e.g. the lightweight/heavyweight stat difference more >> interesting in the shared case. >> >> The filesystem should be able to make that shared/unshared distinction >> without knowledge of the storage it's sitting on top of. >> >> Answering your questions by that criterion: >> >> - ext4/nbd: not shared >> - nfs/lo: shared >> >> But, it's fine with me to drop any features for now as long as we can >> always add them later. > > Please, please, please, let's get the syscall and basic functionality > landed first, and then nit-pick about extensions later. This has been > dragging on for _years_ and bike shedded to death. I very much agree with this, but I think it will require dropping (not replacing yet) things that do not have a well defined meaning, including > STATX_ATTR_KERNEL_API File is kernel API (eg: procfs/sysfs) > STATX_ATTR_REMOTE File is remote and needs network > STATX_ATTR_FABRICATED File was made up by fs Without clear guidance on how the filesystem should choose to set these, and how a program should interpret them, they are worse than noise. I imagine each could possibly be useful, but without clear unambiguous documentation, they aren't. So just remove them for now, and consider adding them once the core syscall has landed. NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 800 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC][PATCH 0/4] Enhanced file stat system call 2016-11-17 16:45 ` David Howells 2016-11-17 20:00 ` J. Bruce Fields @ 2016-11-18 13:41 ` One Thousand Gnomes 2016-11-18 13:49 ` David Howells 2 siblings, 0 replies; 52+ messages in thread From: One Thousand Gnomes @ 2016-11-18 13:41 UTC (permalink / raw) To: David Howells; +Cc: linux-fsdevel, linux-kernel > Hmmm... Interesting question. Probably should. But you could be insane and > RAID an nbd and a local disk. Further, does NFS over a loopback device to > nfsd on the same machine qualify as root? What if that's exposing a local fs > on NBD? Perhaps I should drop 'REMOTE' for now. It sounds like something > that a GUI filemanager might find interesting, though. GUI file managers already try and guess some of this in order to decide whether to display icons off remote file systems. You could be insane but it's always going to be a hint and nothing more and if it can't be perfect then that just goes in the notes in the manual page. Alan ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [RFC][PATCH 0/4] Enhanced file stat system call 2016-11-17 16:45 ` David Howells 2016-11-17 20:00 ` J. Bruce Fields 2016-11-18 13:41 ` One Thousand Gnomes @ 2016-11-18 13:49 ` David Howells 2 siblings, 0 replies; 52+ messages in thread From: David Howells @ 2016-11-18 13:49 UTC (permalink / raw) To: One Thousand Gnomes; +Cc: dhowells, linux-fsdevel, linux-kernel One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote: > > Hmmm... Interesting question. Probably should. But you could be insane and > > RAID an nbd and a local disk. Further, does NFS over a loopback device to > > nfsd on the same machine qualify as root? What if that's exposing a local fs > > on NBD? Perhaps I should drop 'REMOTE' for now. It sounds like something > > that a GUI filemanager might find interesting, though. > > GUI file managers already try and guess some of this in order to decide > whether to display icons off remote file systems. > > You could be insane but it's always going to be a hint and nothing more > and if it can't be perfect then that just goes in the notes in the manual > page. I've dropped REMOTE, FABRICATED, KERNEL_API, NONUNIX_OWNERSHIP, HAS_ACL and UNLISTED_DENTS for now. I'm keeping AUTOMOUNT as that seems fairly straightforward - though I'm sure we can find someone to disagree! ;-) David ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2016-11-22 20:58 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells 2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells 2016-11-17 18:39 ` Jeff Layton 2016-11-18 2:32 ` Andreas Dilger 2016-11-18 8:59 ` David Howells 2016-11-18 8:59 ` David Howells 2016-11-18 9:25 ` Andreas Dilger 2016-11-18 9:25 ` Andreas Dilger 2016-11-17 23:40 ` Dave Chinner 2016-11-18 3:28 ` Andreas Dilger 2016-11-18 22:07 ` Dave Chinner 2016-11-18 22:54 ` David Howells 2016-11-19 22:43 ` Dave Chinner 2016-11-21 14:30 ` One Thousand Gnomes 2016-11-21 20:43 ` Dave Chinner 2016-11-22 10:39 ` David Howells 2016-11-22 13:55 ` Jeff Layton 2016-11-22 20:58 ` Dave Chinner 2016-11-18 9:53 ` David Howells 2016-11-18 8:48 ` David Howells 2016-11-18 12:01 ` Jeff Layton 2016-11-18 9:36 ` David Howells 2016-11-18 17:17 ` Jeff Layton 2016-11-18 18:04 ` David Howells 2016-11-18 18:54 ` Jeff Layton 2016-11-18 19:08 ` David Howells 2016-11-18 9:43 ` David Howells 2016-11-18 21:41 ` Dave Chinner 2016-11-18 22:24 ` David Howells 2016-11-18 10:29 ` David Howells 2016-11-18 10:29 ` David Howells 2016-11-18 21:27 ` Dave Chinner 2016-11-18 21:48 ` David Howells 2016-11-18 21:48 ` David Howells 2016-11-18 22:17 ` Dave Chinner 2016-11-18 22:17 ` Dave Chinner 2016-11-19 10:21 ` Michael Kerrisk (man-pages) 2016-11-17 13:35 ` [PATCH 2/4] statx: Ext4: Return enhanced file attributes David Howells 2016-11-18 3:30 ` Andreas Dilger 2016-11-17 13:35 ` [PATCH 3/4] statx: NFS: " David Howells 2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells 2016-11-18 3:34 ` Andreas Dilger 2016-11-18 8:47 ` David Howells 2016-11-17 14:39 ` [RFC][PATCH 0/4] Enhanced file stat system call One Thousand Gnomes 2016-11-17 15:10 ` Michael Kerrisk 2016-11-17 16:33 ` David Howells 2016-11-17 16:45 ` David Howells 2016-11-17 20:00 ` J. Bruce Fields 2016-11-18 2:30 ` Andreas Dilger 2016-11-18 4:29 ` NeilBrown 2016-11-18 13:41 ` One Thousand Gnomes 2016-11-18 13:49 ` David Howells
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.