| Message ID | 20160429125743.23636.85219.stgit@warthog.procyon.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Apr 29, 2016, at 6:57 AM, David Howells <dhowells@redhat.com> wrote: > > Add a system call to make extended file information available, including > file creation time, inode version and data version where available through > the underlying filesystem. Hi David, thanks for resubmitting the patch series. No requests to add features here, just a couple of comments on the patches regarding the implementation... > ======== > 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_FORCE_ATTR_SYNC can be set in flags. This will require a network > filesystem to synchronise its attributes with the server. > > AT_NO_ATTR_SYNC can be set in flags. This will suppress synchronisation > with the server in a network filesystem. The resulting values should be > considered approximate. > > 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(). > > 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 st_mask; > __u32 st_information; > __u32 st_blksize; > __u32 st_nlink; > __u32 st_gen; > __u32 st_uid; > __u32 st_gid; > __u16 st_mode; > __u16 __spare0[1]; > __u64 st_ino; > __u64 st_size; > __u64 st_blocks; > __u64 st_version; > __s64 st_atime; > __s64 st_btime; > __s64 st_ctime; > __s64 st_mtime; > __s32 st_atime_ns; > __s32 st_btime_ns; > __s32 st_ctime_ns; > __s32 st_mtime_ns; > __u32 st_rdev_major; > __u32 st_rdev_minor; > __u32 st_dev_major; > __u32 st_dev_minor; > __u64 __spare1[16]; > }; > > where st_information is local system information about the file, st_gen is > the inode generation number, st_btime is the file creation time, st_version > is the data version number (i_version), st_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 should also be negative if not zero. > > The defined bits in request_mask and st_mask are: > > STATX_MODE Want/got st_mode > STATX_NLINK Want/got st_nlink > STATX_UID Want/got st_uid > STATX_GID Want/got st_gid > STATX_RDEV Want/got st_rdev_* > STATX_ATIME Want/got st_atime > STATX_MTIME Want/got st_mtime > STATX_CTIME Want/got st_ctime > STATX_INO Want/got st_ino > STATX_SIZE Want/got st_size > STATX_BLOCKS Want/got st_blocks > STATX_BASIC_STATS [The stuff in the normal stat struct] > STATX_BTIME Want/got st_btime > STATX_VERSION Want/got st_data_version > STATX_GEN Want/got st_gen > STATX_ALL_STATS [All currently available stuff] > > The defined bits in the st_information field give local system data on a > file, how it is accessed, where it is and what it does: > > STATX_INFO_ENCRYPTED File is encrypted This flag overlaps with FS_ENCRYPT_FL that is encoded in the FS_IOC_GETFLAGS attributes. Are the FS_* flags expected to be translated into STATX_INFO_* flags by each filesystem, or will they be partly duplicated in a separate "st_attrs" field added in the future? Cheers, Andreas > STATX_INFO_TEMPORARY File is temporary > STATX_INFO_FABRICATED File was made up by filesystem > STATX_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs) > STATX_INFO_REMOTE File is remote > STATX_INFO_AUTOMOUNT Dir is automount trigger > STATX_INFO_AUTODIR Dir provides unlisted automounts > STATX_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details > > 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) st_information, st_dev_*, st_blksize. > > These are local data and are always available. > > (1) st_nlinks, st_uid, st_gid, st_[amc]time*, st_ino, st_size, st_blocks. > > These will be returned whether the caller asks for them or not. The > corresponding bits in st_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 st_mask, > even if the caller asked for the value. In such a case, the returned > value will be a fabrication. > > (2) st_mode. > > The part of this that identifies the file type will always be > available, irrespective of the setting of STATX_MODE. The access > flags and sticky bit are as for class (1). > > (3) st_rdev_*. > > As for class (1), but this will be cleared if the file is not a > blockdev or chardev. The bit will be cleared if the value is not > returned. > > (4) File creation time (st_btime*), data version (st_version), inode > generation number (st_gen). > > These will be returned if available whether the caller asked for them or > not. The corresponding bits in st_mask will be set or cleared as > appropriate to indicate a valid value. > > 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. > > > ======= > 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=4fef > Size: 4096 Blocks: 8 IO Block: 1048576 directory > Device: 00:1d Inode: 2 Links: 110 > Access: (3777/drwxrwxrwx) Uid: -2 > Gid: 4294967294 > Access: 2012-04-30 09:01:55.283819565+0100 > Modify: 2012-03-28 19:01:19.405465361+0100 > Change: 2012-03-28 19:01:19.405465361+0100 > Data version: ef51734f11e92a18h > Information: 00000134 (-------- -------- -------a --mr-f--) > > Secondly, the result of automounting on that directory. > > [root@andromeda tmp]# ./samples/statx/test-statx /warthog/data > statx(/warthog/data) = 0 > results=14fef > Size: 4096 Blocks: 8 IO Block: 1048576 directory > Device: 00:1e Inode: 2 Links: 110 > Access: (3777/drwxrwxrwx) Uid: -2 > Gid: 4294967294 > Access: 2012-04-30 09:01:55.283819565+0100 > Modify: 2012-03-28 19:01:19.405465361+0100 > Change: 2012-03-28 19:01:19.405465361+0100 > Data version: ef51734f11e92a18h > Information: 00000110 (-------- -------- -------a ---r----) > > 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 | 303 +++++++++++++++++++++++++++++--- > include/linux/fs.h | 5 - > include/linux/stat.h | 15 +- > include/linux/syscalls.h | 4 > include/uapi/linux/fcntl.h | 2 > include/uapi/linux/stat.h | 109 ++++++++++++ > samples/Makefile | 2 > samples/statx/Makefile | 10 + > samples/statx/test-statx.c | 243 ++++++++++++++++++++++++++ > 12 files changed, 662 insertions(+), 37 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 b30dd8154cc2..b99a6b3a167c 100644 > --- a/arch/x86/entry/syscalls/syscall_32.tbl > +++ b/arch/x86/entry/syscalls/syscall_32.tbl > @@ -386,3 +386,4 @@ > 377 i386 copy_file_range sys_copy_file_range > 378 i386 preadv2 sys_preadv2 > 379 i386 pwritev2 sys_pwritev2 > +380 i386 statx sys_statx > diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl > index cac6d17ce5db..6d5ef6c87cdc 100644 > --- a/arch/x86/entry/syscalls/syscall_64.tbl > +++ b/arch/x86/entry/syscalls/syscall_64.tbl > @@ -335,6 +335,7 @@ > 326 common copy_file_range sys_copy_file_range > 327 64 preadv2 sys_preadv2 > 328 64 pwritev2 sys_pwritev2 > +329 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 c46f1a190b8d..cd6d9cbc9300 100644 > --- a/fs/exportfs/expfs.c > +++ b/fs/exportfs/expfs.c > @@ -295,7 +295,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..c2f8370dab13 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,197 @@ 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 & ~STATX_RDEV; > + if (IS_NOATIME(inode)) > + stat->result_mask &= ~STATX_ATIME; > + else > + stat->atime = inode->i_atime; > + > + if (S_ISREG(stat->mode) && stat->nlink == 0) > + stat->information |= STATX_INFO_TEMPORARY; > + if (IS_AUTOMOUNT(inode)) > + stat->information |= STATX_INFO_AUTOMOUNT; > + > + if (unlikely(S_ISBLK(stat->mode) || S_ISCHR(stat->mode))) > + stat->result_mask |= STATX_RDEV; > +} > 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; > + if ((stat->query_flags & AT_FORCE_ATTR_SYNC) && > + (stat->query_flags & AT_NO_ATTR_SYNC)) > + return -EINVAL; > + > + stat->result_mask = 0; > + stat->information = 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 +235,65 @@ retry: > 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 +308,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 +333,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 +610,80 @@ 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->st_mask ) || > + __put_user(stat->mode, &buffer->st_mode ) || > + __clear_user(&buffer->__spare0, sizeof(buffer->__spare0)) || > + __put_user(stat->nlink, &buffer->st_nlink ) || > + __put_user(uid, &buffer->st_uid ) || > + __put_user(gid, &buffer->st_gid ) || > + __put_user(stat->information, &buffer->st_information ) || > + __put_user(stat->blksize, &buffer->st_blksize ) || > + __put_user(MAJOR(stat->rdev), &buffer->st_rdev_major ) || > + __put_user(MINOR(stat->rdev), &buffer->st_rdev_minor ) || > + __put_user(MAJOR(stat->dev), &buffer->st_dev_major ) || > + __put_user(MINOR(stat->dev), &buffer->st_dev_minor ) || > + __put_timestamp(stat->atime, &buffer->st_atime ) || > + __put_timestamp(stat->btime, &buffer->st_btime ) || > + __put_timestamp(stat->ctime, &buffer->st_ctime ) || > + __put_timestamp(stat->mtime, &buffer->st_mtime ) || > + __put_user(stat->ino, &buffer->st_ino ) || > + __put_user(stat->size, &buffer->st_size ) || > + __put_user(stat->blocks, &buffer->st_blocks ) || > + __put_user(stat->version, &buffer->st_version ) || > + __put_user(stat->gen, &buffer->st_gen ) || > + __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_STATS; > + > + 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 70e61b58baaf..8b2f6df924e9 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -2827,8 +2827,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); > @@ -2845,6 +2846,8 @@ extern int vfs_stat(const char __user *, struct kstat *); > 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 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..4f1902b0cb94 100644 > --- a/include/linux/stat.h > +++ b/include/linux/stat.h > @@ -19,6 +19,13 @@ > #include <linux/uidgid.h> > > struct kstat { > + u32 query_flags; /* Operational flags */ > +#define KSTAT_QUERY_FLAGS (AT_FORCE_ATTR_SYNC | AT_NO_ATTR_SYNC) > + u32 request_mask; /* What fields the user asked for */ > + u32 result_mask; /* What fields the user got */ > + u32 information; > + u32 win_attrs; /* Windows file attributes */ > + u32 gen; > u64 ino; > dev_t dev; > umode_t mode; > @@ -27,11 +34,13 @@ struct kstat { > 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 */ > + uint32_t blksize; /* Preferred I/O size */ > + u64 blocks; > + u64 version; /* Data version */ > }; > > #endif > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h > index d795472c54d8..f6bfbf74e44d 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; > @@ -898,4 +899,7 @@ asmlinkage long sys_copy_file_range(int fd_in, loff_t __user *off_in, > > asmlinkage long sys_mlock2(unsigned long start, size_t len, int flags); > > +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..5c8143b04ff7 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_FORCE_ATTR_SYNC 0x2000 /* Force the attributes to be sync'd with the server */ > +#define AT_NO_ATTR_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..55ce6607dab6 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,113 @@ > > #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 available at all, the field and the bit will both be > + * cleared; > + * > + * - otherwise, if explicitly requested: > + * > + * - the datum will be synchronised to the server if AT_FORCE_ATTR_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 st_mask; /* What results were written [uncond] */ > + __u32 st_information; /* Information about the file [uncond] */ > + __u32 st_blksize; /* Preferred general I/O size [uncond] */ > + __u32 st_nlink; /* Number of hard links */ > + /* 0x10 */ > + __u32 st_gen; /* Inode generation number */ > + __u32 st_uid; /* User ID of owner */ > + __u32 st_gid; /* Group ID of owner */ > + __u16 st_mode; /* File mode */ > + __u16 __spare0[1]; > + /* 0x20 */ > + __u64 st_ino; /* Inode number */ > + __u64 st_size; /* File size */ > + __u64 st_blocks; /* Number of 512-byte blocks allocated */ > + __u64 st_version; /* Data version number */ > + /* 0x40 */ > + __s64 st_atime_s; /* Last access time */ > + __s64 st_btime_s; /* File creation time */ > + __s64 st_ctime_s; /* Last attribute change time */ > + __s64 st_mtime_s; /* Last data modification time */ > + /* 0x60 */ > + __s32 st_atime_ns; /* Last access time (ns part) */ > + __s32 st_btime_ns; /* File creation time (ns part) */ > + __s32 st_ctime_ns; /* Last attribute change time (ns part) */ > + __s32 st_mtime_ns; /* Last data modification time (ns part) */ > + /* 0x70 */ > + __u32 st_rdev_major; /* Device ID of special file */ > + __u32 st_rdev_minor; > + __u32 st_dev_major; /* ID of device containing file [uncond] */ > + __u32 st_dev_minor; > + /* 0x80 */ > + __u64 __spare1[16]; /* Spare space for future expansion */ > + /* 0x100 */ > +}; > + > +/* > + * Flags to be st_mask > + * > + * Query request/result mask for statx() and struct statx::st_mask. > + * > + * These bits should be set in the mask argument of statx() to request > + * particular items when calling statx(). > + */ > +#define STATX_MODE 0x00000001U /* Want/got st_mode */ > +#define STATX_NLINK 0x00000002U /* Want/got st_nlink */ > +#define STATX_UID 0x00000004U /* Want/got st_uid */ > +#define STATX_GID 0x00000008U /* Want/got st_gid */ > +#define STATX_RDEV 0x00000010U /* Want/got st_rdev */ > +#define STATX_ATIME 0x00000020U /* Want/got st_atime */ > +#define STATX_MTIME 0x00000040U /* Want/got st_mtime */ > +#define STATX_CTIME 0x00000080U /* Want/got st_ctime */ > +#define STATX_INO 0x00000100U /* Want/got st_ino */ > +#define STATX_SIZE 0x00000200U /* Want/got st_size */ > +#define STATX_BLOCKS 0x00000400U /* Want/got st_blocks */ > +#define STATX_BASIC_STATS 0x000007ffU /* The stuff in the normal stat struct */ > +#define STATX_BTIME 0x00000800U /* Want/got st_btime */ > +#define STATX_VERSION 0x00001000U /* Want/got st_version */ > +#define STATX_GEN 0x00002000U /* Want/got st_gen */ > +#define STATX_ALL_STATS 0x00003fffU /* All supported stats */ > + > +/* > + * Flags to be found in st_information > + * > + * 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. > + */ > +#define STATX_INFO_ENCRYPTED 0x00000001U /* File is encrypted */ > +#define STATX_INFO_TEMPORARY 0x00000002U /* File is temporary */ > +#define STATX_INFO_FABRICATED 0x00000004U /* File was made up by filesystem */ > +#define STATX_INFO_KERNEL_API 0x00000008U /* File is kernel API (eg: procfs/sysfs) */ > +#define STATX_INFO_REMOTE 0x00000010U /* File is remote */ > +#define STATX_INFO_AUTOMOUNT 0x00000020U /* Dir is automount trigger */ > +#define STATX_INFO_AUTODIR 0x00000040U /* Dir provides unlisted automounts */ > +#define STATX_INFO_NONSYSTEM_OWNERSHIP 0x00000080U /* File has non-system ownership details */ > > #endif /* _UAPI_LINUX_STAT_H */ > diff --git a/samples/Makefile b/samples/Makefile > index 48001d7e23f0..d2ebb4e48d19 100644 > --- a/samples/Makefile > +++ b/samples/Makefile > @@ -2,4 +2,4 @@ > > obj-$(CONFIG_SAMPLES) += kobject/ kprobes/ trace_events/ livepatch/ \ > hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ \ > - configfs/ > + configfs/ statx/ > diff --git a/samples/statx/Makefile b/samples/statx/Makefile > new file mode 100644 > index 000000000000..6765dabc4c8d > --- /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-y := 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..38ef23c12e7d > --- /dev/null > +++ b/samples/statx/test-statx.c > @@ -0,0 +1,243 @@ > +/* 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_FORCE_ATTR_SYNC 0x2000 > +#define AT_NO_ATTR_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->st_mask); > + > + printf(" "); > + if (stx->st_mask & STATX_SIZE) > + printf(" Size: %-15llu", (unsigned long long)stx->st_size); > + if (stx->st_mask & STATX_BLOCKS) > + printf(" Blocks: %-10llu", (unsigned long long)stx->st_blocks); > + printf(" IO Block: %-6llu ", (unsigned long long)stx->st_blksize); > + if (stx->st_mask & STATX_MODE) { > + switch (stx->st_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->st_mode & S_IFMT); > + break; > + } > + } > + > + sprintf(buffer, "%02x:%02x", stx->st_dev_major, stx->st_dev_minor); > + printf("Device: %-15s", buffer); > + if (stx->st_mask & STATX_INO) > + printf(" Inode: %-11llu", (unsigned long long) stx->st_ino); > + if (stx->st_mask & STATX_SIZE) > + printf(" Links: %-5u", stx->st_nlink); > + if (stx->st_mask & STATX_RDEV) > + printf(" Device type: %u,%u", stx->st_rdev_major, stx->st_rdev_minor); > + printf("\n"); > + > + if (stx->st_mask & STATX_MODE) > + printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c) ", > + stx->st_mode & 07777, > + ft, > + stx->st_mode & S_IRUSR ? 'r' : '-', > + stx->st_mode & S_IWUSR ? 'w' : '-', > + stx->st_mode & S_IXUSR ? 'x' : '-', > + stx->st_mode & S_IRGRP ? 'r' : '-', > + stx->st_mode & S_IWGRP ? 'w' : '-', > + stx->st_mode & S_IXGRP ? 'x' : '-', > + stx->st_mode & S_IROTH ? 'r' : '-', > + stx->st_mode & S_IWOTH ? 'w' : '-', > + stx->st_mode & S_IXOTH ? 'x' : '-'); > + if (stx->st_mask & STATX_UID) > + printf("Uid: %5d ", stx->st_uid); > + if (stx->st_mask & STATX_GID) > + printf("Gid: %5d\n", stx->st_gid); > + > + if (stx->st_mask & STATX_ATIME) > + print_time("Access: ", stx->st_atime_s, stx->st_atime_ns); > + if (stx->st_mask & STATX_MTIME) > + print_time("Modify: ", stx->st_mtime_s, stx->st_mtime_ns); > + if (stx->st_mask & STATX_CTIME) > + print_time("Change: ", stx->st_ctime_s, stx->st_ctime_ns); > + if (stx->st_mask & STATX_BTIME) > + print_time(" Birth: ", stx->st_btime_s, stx->st_btime_ns); > + > + if (stx->st_mask & STATX_VERSION) > + printf("Data version: %llxh\n", > + (unsigned long long)stx->st_version); > + > + if (stx->st_mask & STATX_GEN) > + printf("Inode gen : %xh\n", stx->st_gen); > + > + if (stx->st_information) { > + unsigned char bits; > + int loop, byte; > + > + static char info_representation[32 + 1] = > + /* STATX_INFO_ flags: */ > + "????????" /* 31-24 0x00000000-ff000000 */ > + "????????" /* 23-16 0x00000000-00ff0000 */ > + "????????" /* 15- 8 0x00000000-0000ff00 */ > + "ndmrkfte" /* 7- 0 0x00000000-000000ff */ > + ; > + > + printf("Information: %08x (", stx->st_information); > + for (byte = 32 - 8; byte >= 0; byte -= 8) { > + bits = stx->st_information >> byte; > + for (loop = 7; loop >= 0; loop--) { > + int bit = byte + loop; > + > + if (bits & 0x80) > + putchar(info_representation[31 - bit]); > + else > + putchar('-'); > + bits <<= 1; > + } > + if (byte) > + putchar(' '); > + } > + printf(")\n"); > + } > + > + printf("IO-blocksize: blksize=%u\n", stx->st_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_STATS; > + > + for (argv++; *argv; argv++) { > + if (strcmp(*argv, "-F") == 0) { > + atflag |= AT_FORCE_ATTR_SYNC; > + continue; > + } > + if (strcmp(*argv, "-N") == 0) { > + atflag |= AT_NO_ATTR_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 Cheers, Andreas
Andreas Dilger <adilger@dilger.ca> wrote: > > STATX_INFO_ENCRYPTED File is encrypted > > This flag overlaps with FS_ENCRYPT_FL that is encoded in the FS_IOC_GETFLAGS > attributes. Are the FS_* flags expected to be translated into STATX_INFO_* > flags by each filesystem, or will they be partly duplicated in a separate > "st_attrs" field added in the future? I think that most of the FS_IOC_GETFLAGS flags are sufficiently specialised that they aren't something the ordinary user would necessarily find to be of interest, so I'm not sure that mapping all of them to STATX_INFO_* flags is necessary. That said, I think STATX_INFO_ENCRYPTED *is* usefully deployed here to tell the user that the file or directory is encrypted and that the user will have to unlock or provide a key to access it. I'm also thinking that a STATX_INFO_NEED_AUTHENTICATION flag may be needed to indicate that the user must authenticate in some way (probably only applicable to network files) to be able to access the file. 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
On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote: > (4) File creation time (st_btime*), data version (st_version), inode > generation number (st_gen). > > These will be returned if available whether the caller asked for them or > not. The corresponding bits in st_mask will be set or cleared as > appropriate to indicate a valid value. IMO, exposing the inode generation number to anyone is a potential security problem because they are used in file handles. Most file handles provided by filesystems are simply an encoding of the inode number + generation number, plus maybe the ino+gen of the parent dir if the NFS server is configured to do this. This makes it trivial for an attacker to guess what the likely generation numbers are going to be for inode numbers surrounding any given inode, hence greatly reducing the search space for guessing valid file handles. We've known this to be a problem for a long time - file handles are not cryptographically secure, so exposing information like this by default make guessing handles successfully almost trivial for many filesystems. In the latest XFS filesystem format, we randomise the generation value during every inode allocation to make it hard to guess the handle of adjacent inodes from an existing ino+gen pair, or even from life time to life time of the same inode. We don't use a secure random number generator (prandom_u32()) so it's still possible to guess with enough trial and observation. However, it makes it several orders of magnitude harder to guess and requires knowledge of inode allocation order to guess correctly once the random number sequence has been deduced and so makes brute force the only real option for guessing a valid handle for an inode. However, this is definitely a problem for the older format where each cluster of inodes was initialised with the same seed at cluster allocation time and the generation number was simply incremented for each life time. Most filesystems use a similar method for seeding and incrementing generation numbers, so once the generation numbers are exposed it makes handles trivial to calculate successfully. > 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. I would suggest that exposing them from the NFS server is something we most definitely don't want to do because they are the only thing that keeps remote users from guessing filehandles with ease.... Cheers, Dave.
On Fri, Apr 29 2016, David Howells wrote: > Add a system call to make extended file information available, including > file creation time, inode version and data version where available through > the underlying filesystem. > > > ======== > OVERVIEW > ======== I think all this documentation is invaluable - thanks. I would really like to see much of it in Documentation/filesystems/something.txt rather than just in the commit log. > > The defined bits in the st_information field give local system data on a > file, how it is accessed, where it is and what it does: These bits form a channel for communication between the filesystem developer and the application writer. As such we should be sure that channel actually communicates meaning... > > STATX_INFO_ENCRYPTED File is encrypted > STATX_INFO_TEMPORARY File is temporary What is "temporary"? Is it a statement about quality of storage technology (will be destroyed by reboot) or intention of creator (created with O_TMPFILE) or something else? > STATX_INFO_FABRICATED File was made up by filesystem > STATX_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs) What is the difference between these two? Both are synthesized by the kernel. Maybe the "KERNEL_API" is declared never to change its meaning, while the fabricated one doesn't make a "stable API" promise? What is the difference between fabricating a file from a bunch of blocks spread over a storage device, and fabricating a file from a single field in the super-block? > STATX_INFO_REMOTE File is remote How far is "remote"? Does Infiniband count? Fibre channel? iSCSI? Is a file on a loop-back mounted NFS filesystem more remote than a fibre-channel connection to the next town? Or is this relative? Within a filesystem there are "remote" files and "non-remote" files and the distinction is filesystem-dependant?? > STATX_INFO_AUTOMOUNT Dir is automount trigger > STATX_INFO_AUTODIR Dir provides unlisted automounts I think this last one means that there are names in the directory which may not appear in "readdir" but will respond to "stat". I would prefer the description to match the behavior without necessarily implying that those names will be automounts. e.g STATX_INFO_INCOMPLETE_READDIR getdents may not report all names that respond to stat > STATX_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details This probably is a well defined meaning that I just don't have the context to understand. For me, more words would help here. I don't object to any of these flag. I just want to be sure that I understand them. I am generally in favour this functionality going in promptly. Thanks, NeilBrown
On Thu, May 05 2016, Dave Chinner wrote: > On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote: >> (4) File creation time (st_btime*), data version (st_version), inode >> generation number (st_gen). >> >> These will be returned if available whether the caller asked for them or >> not. The corresponding bits in st_mask will be set or cleared as >> appropriate to indicate a valid value. > > IMO, exposing the inode generation number to anyone is a potential > security problem because they are used in file handles. "security through obscurity". We have Kerberos working really nicely for NFS these days. Do we still care? What if the generation number were only made available to "root"? Would that allay your concerns? Would that still be useful? We already have name_to_handle_at(). Exposing the generation number could/should follow the same rules at that. Or maybe the exposure of each field should be guided by the filesystem, depending on (for example) whether it is used to provide uniqueness to the filehandle. > >> 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. > > I would suggest that exposing them from the NFS server is something > we most definitely don't want to do because they are the only thing > that keeps remote users from guessing filehandles with ease.... Given that the NFS protocol does not define a "generation number" attribute, I think there is no risk for them being exposed from the NFS server ... except implicitly within the filehandle of course. NeilBrown
On Thu, 2016-05-05 at 10:09 +1000, NeilBrown wrote: > On Thu, May 05 2016, Dave Chinner wrote: > > > > > On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote: > > > > > >  (4) File creation time (st_btime*), data version (st_version), inode > > >      generation number (st_gen). > > > > > >      These will be returned if available whether the caller asked for them or > > >      not.  The corresponding bits in st_mask will be set or cleared as > > >      appropriate to indicate a valid value. > > IMO, exposing the inode generation number to anyone is a potential > > security problem because they are used in file handles. > "security through obscurity".  We have Kerberos working really nicely > for NFS these days.  Do we still care? > > What if the generation number were only made available to "root"?  Would > that allay your concerns? > Would that still be useful? > We already have name_to_handle_at().  Exposing the generation number > could/should follow the same rules at that.  Or maybe the exposure of > each field should be guided by the filesystem, depending on (for > example) whether it is used to provide uniqueness to the filehandle. > > > > > > > > > > >      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. > > I would suggest that exposing them from the NFS server is something > > we most definitely don't want to do because they are the only thing > > that keeps remote users from guessing filehandles with ease.... > Given that the NFS protocol does not define a "generation number" > attribute, I think there is no risk for them being exposed from the NFS > server ... except implicitly within the filehandle of course. > > NeilBrown I don't see a real attack vector here either, but OTOH is there a potential user of this at the moment? An earlier chunk of the patch description says: (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 ...the last bit seems to indicate that we don't really need this anyway, as most userland servers now work with filehandles from the kernel. Maybe leave it out for now? It can always be added later.
Jeff Layton <jlayton@poochiereds.net> wrote: > I don't see a real attack vector here either, but OTOH is there a > potential user of this at the moment? I'm not sure. BSD stat has an st_gen, so it's possible something out there will use it if it exists. > An earlier chunk of the patch description says: > > (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 > > ...the last bit seems to indicate that we don't really need this > anyway, as most userland servers now work with filehandles from the > kernel. > > Maybe leave it out for now? It can always be added later. Yeah... probably a good idea. 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
On Thu, May 05, 2016 at 09:04:09PM +0100, David Howells wrote: > Jeff Layton <jlayton@poochiereds.net> wrote: > > > I don't see a real attack vector here either, but OTOH is there a > > potential user of this at the moment? > > I'm not sure. BSD stat has an st_gen, so it's possible something out there > will use it if it exists. Oh, I know of several userspace applications that use the inode generation number for some purpose. However, all of them are so tightly tied to the XFS internal structure, implementation and the XFS specific bulkstat interface that they cannot be considered generic applications. > > An earlier chunk of the patch description says: > > > > (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 > > > > ...the last bit seems to indicate that we don't really need this > > anyway, as most userland servers now work with filehandles from the > > kernel. > > > > Maybe leave it out for now? It can always be added later. > > Yeah... probably a good idea. Fine by me. Cheers, Dave.
On Thu, May 05, 2016 at 03:48:16PM -0400, Jeff Layton wrote: > On Thu, 2016-05-05 at 10:09 +1000, NeilBrown wrote: > > On Thu, May 05 2016, Dave Chinner wrote: > > > > > > > > On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote: > > > > > > > >  (4) File creation time (st_btime*), data version (st_version), inode > > > >      generation number (st_gen). > > > > > > > >      These will be returned if available whether the caller asked for them or > > > >      not.  The corresponding bits in st_mask will be set or cleared as > > > >      appropriate to indicate a valid value. > > > IMO, exposing the inode generation number to anyone is a potential > > > security problem because they are used in file handles. > > "security through obscurity".  We have Kerberos working really nicely > > for NFS these days.  Do we still care? > > > > What if the generation number were only made available to "root"?  Would > > that allay your concerns? > > Would that still be useful? > > We already have name_to_handle_at().  Exposing the generation number > > could/should follow the same rules at that.  Or maybe the exposure of > > each field should be guided by the filesystem, depending on (for > > example) whether it is used to provide uniqueness to the filehandle. > > > > > > > > > > > > > > > >      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. > > > I would suggest that exposing them from the NFS server is something > > > we most definitely don't want to do because they are the only thing > > > that keeps remote users from guessing filehandles with ease.... > > Given that the NFS protocol does not define a "generation number" > > attribute, I think there is no risk for them being exposed from the NFS > > server ... except implicitly within the filehandle of course. > > > > NeilBrown > > > > I don't see a real attack vector here either, but OTOH is there a > potential user of this at the moment? An earlier chunk of the patch > description says: > > (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 > > ...the last bit seems to indicate that we don't really need this > anyway, as most userland servers now work with filehandles from the > kernel. > > Maybe leave it out for now? It can always be added later. Sounds like a good compromise to me! That said, filehandles can never be changed, and generally have to be exposed on the network, so I don't think it's worth going to great lengths to try keep them secret. --b. -- 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
On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote: > IMO, exposing the inode generation number to anyone is a potential > security problem because they are used in file handles. > > Most file handles provided by filesystems are simply an encoding of > the inode number + generation number, plus maybe the ino+gen of the > parent dir if the NFS server is configured to do this. This makes it > trivial for an attacker to guess what the likely generation numbers > are going to be for inode numbers surrounding any given inode, hence > greatly reducing the search space for guessing valid file handles. > > We've known this to be a problem for a long time - file handles are > not cryptographically secure, I once thought signing filehandles cryptographically to prevent spoofing would be interesting. But once you've handed out a filehandle, it's hard to keep it secret. And the server's required to respect a file's filehandle for the lifetime of the file, so it only has to leak once. So I'm no longer convinced it's worth going to that kind of trouble. Just choosing the generation number randomly, OK, maybe that's a reasonable measure. > so exposing information like this by > default make guessing handles successfully almost trivial for many > filesystems. > > In the latest XFS filesystem format, we randomise the generation > value during every inode allocation to make it hard to guess the > handle of adjacent inodes from an existing ino+gen pair, or even > from life time to life time of the same inode. The one thing I wonder about is whether that increases the probability of a filehandle collision (where you accidentally generate the same filehandle for two different files). If the generation number is a 32-bit counter per inode number (is that actually the way filesystems work?), then it takes 2^32 reuses of the inode number to hit the same filehandle. If you choose it randomly then you expect a collision after about 2^16 reuses. I don't know, maybe this is still unlikely enough to be academic. > We don't use a secure > random number generator (prandom_u32()) so it's still possible to > guess with enough trial and observation. However, it makes it > several orders of magnitude harder to guess and requires knowledge > of inode allocation order to guess correctly once the random number > sequence has been deduced and so makes brute force the only real > option for guessing a valid handle for an inode. > > However, this is definitely a problem for the older format where > each cluster of inodes was initialised with the same seed at cluster > allocation time and the generation number was simply incremented for > each life time. Most filesystems use a similar method for seeding > and incrementing generation numbers, so once the generation numbers > are exposed it makes handles trivial to calculate successfully. > > > 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. > > I would suggest that exposing them from the NFS server is something > we most definitely don't want to do because they are the only thing > that keeps remote users from guessing filehandles with ease.... The first line of defense is not to depend on unguessable filehandles. (Don't export sudirectories unless you're willing to export the whole filesystem; and don't depend on directory permissions to keep children secret.) --b. -- 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
> int ret = statx(int dfd, > const char *filename, > unsigned int flags, > unsigned int mask, > struct statx *buffer); Please move the flags and mask after the buffer, similar to how all the AT_ flags were added to the end for the statat calls. > AT_FORCE_ATTR_SYNC can be set in flags. This will require a network > filesystem to synchronise its attributes with the server. > > AT_NO_ATTR_SYNC can be set in flags. This will suppress synchronisation > with the server in a network filesystem. The resulting values should be > considered approximate. And what happens if neither is set? > 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(). No a very good name for the constant. I don't really see how this macro is useful to start with. And _ALL? sure, but what's basic? > buffer points to the destination for the data. This must be 256 bytes in > size. 256 bytes or sizeof(struct statx)? Even if they end up the same the latter is a much more useful value. > where st_information is local system information about the file, What the heck is "local system information"? Please define each newly added field in detail. > st_gen is > the inode generation number, st_btime is the file creation time, st_version > is the data version number (i_version), Please define semantics for st_gen and st_version. > 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 should also be negative if not zero. Please coordinate with Arnd on the timespamp format - I'd hate to have a different encoding than he plans for all y2028/64-bit-time_t syscalls to be added soon. > STATX_MTIME Want/got st_mtime > STATX_CTIME Want/got st_ctime > STATX_INO Want/got st_ino > STATX_SIZE Want/got st_size > STATX_BLOCKS Want/got st_blocks > STATX_BASIC_STATS [The stuff in the normal stat struct] > STATX_BTIME Want/got st_btime > STATX_VERSION Want/got st_data_version What is st_data_version? > STATX_GEN Want/got st_gen > STATX_ALL_STATS [All currently available stuff] Where does the STATS_ come from? Why no simply _ALL? How are the semantics defined when userspace asks for fields not available? I'd expect them to be ignored, but we should documentat that fact. > The defined bits in the st_information field give local system data on a > file, how it is accessed, where it is and what it does: Oh, here we get st_information. The name sounds very wrong for these flags, though. > STATX_INFO_ENCRYPTED File is encrypted How do you define "encrypted", and what can the user do with this information? > STATX_INFO_TEMPORARY File is temporary How do you define "temporary", and what can the user do with this information? > STATX_INFO_FABRICATED File was made up by filesystem How do you define "fabricated", and what can the user do with this information? > STATX_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs) How do you define "kernel API" and what can the user do with this information? > STATX_INFO_REMOTE File is remote How do you define "remote" and what can the user do with this information? > STATX_INFO_AUTOMOUNT Dir is automount trigger How do you define "automount trigger" and what can the user do with this information? > STATX_INFO_AUTODIR Dir provides unlisted automounts How do you define "unlisted automount" and what can the user do with this information? > STATX_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details How do you define "non-system ownership" and what can the user do with this information? > > These are for the use of GUI tools that might want to mark files specially, > depending on what they are. So far I don't see good definition of either flag, nor a good reason to add. > Fields in struct statx come in a number of classes: I really disagree with all these special cases. You should get what you ask for, or rather what you ask for IFF the fs can provide it. And we need to document for each field if it's optional if we want to treat it as option. A hodge podge bag of special cases is not an API that a normal person can use. > The following test program can be used to test the statx system call: > > samples/statx/test-statx.c Please add xfstests test cases that test all the corner cases. And please prepare a man page to document this system call properly. -- 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
[ OT, but I'll reply anyway :P ] On Fri, May 06, 2016 at 02:29:23PM -0400, J. Bruce Fields wrote: > On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote: > > In the latest XFS filesystem format, we randomise the generation > > value during every inode allocation to make it hard to guess the > > handle of adjacent inodes from an existing ino+gen pair, or even > > from life time to life time of the same inode. > > The one thing I wonder about is whether that increases the probability > of a filehandle collision (where you accidentally generate the same > filehandle for two different files). Not possible - inode number is still different between the two files. i.e. ino+gen makes the handle unique, not gen. > If the generation number is a 32-bit counter per inode number (is that > actually the way filesystems work?), then it takes 2^32 reuses of the > inode number to hit the same filehandle. 4 billion unlink/create operations that hit the same inode number are going to take some time. I suspect someone will notice the load generated by an attmept to brute force this sort of thing ;) > If you choose it randomly then > you expect a collision after about 2^16 reuses. I'm pretty sure that a random search will need to, on average, search half the keyspace before a match is found (i.e. 2^31 attempts, not 2^16). > > > 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. > > > > I would suggest that exposing them from the NFS server is something > > we most definitely don't want to do because they are the only thing > > that keeps remote users from guessing filehandles with ease.... > > The first line of defense is not to depend on unguessable filehandles. > (Don't export sudirectories unless you're willing to export the whole > filesystem; and don't depend on directory permissions to keep children > secret.) Defense in depth also says "don't make it easy to guess filehandles" because not everyone knows this is a problem. In many cases, users may not even know what consitutes a "filesystem" because their NFS server appliance only defines "exports". The underlying implementation may, in fact, be "everything exported from a single filesystem" and so the user has no choice in the matter.... Dave.
On Mon, May 09, 2016 at 11:45:43AM +1000, Dave Chinner wrote: > [ OT, but I'll reply anyway :P ] > > On Fri, May 06, 2016 at 02:29:23PM -0400, J. Bruce Fields wrote: > > On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote: > > > In the latest XFS filesystem format, we randomise the generation > > > value during every inode allocation to make it hard to guess the > > > handle of adjacent inodes from an existing ino+gen pair, or even > > > from life time to life time of the same inode. > > > > The one thing I wonder about is whether that increases the probability > > of a filehandle collision (where you accidentally generate the same > > filehandle for two different files). > > Not possible - inode number is still different between the two > files. i.e. ino+gen makes the handle unique, not gen. > > > If the generation number is a 32-bit counter per inode number (is that > > actually the way filesystems work?), then it takes 2^32 reuses of the > > inode number to hit the same filehandle. > > 4 billion unlink/create operations that hit the same inode number > are going to take some time. I suspect someone will notice the load > generated by an attmept to brute force this sort of thing ;) > > > If you choose it randomly then > > you expect a collision after about 2^16 reuses. > > I'm pretty sure that a random search will need to, on average, > search half the keyspace before a match is found (i.e. 2^31 > attempts, not 2^16). Yeah, but I was wondering whether you could somehow get into the situation where clients between then are caching N distinct filehandles with the same inode number. Then a collision becomes likely around 2^16, by the usual birthday paradox rule-of-thumb. Uh, but now that I think of it that's irrelevant. At most one of those filehandles actually refers to a still-existing file. Any attempt to use the other 2^16-1 should return -ESTALE. So collisions among that set don't matter, it's only collisions involving the existing file that are interesting. So, nevermind, I can't see a practical way to hit a problem here.... --b. -- 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
On Sun, 2016-05-08 at 01:35 -0700, Christoph Hellwig wrote: > > > > int ret = statx(int dfd, > > const char *filename, > > unsigned int flags, > > unsigned int mask, > > struct statx *buffer); > > Please move the flags and mask after the buffer, similar to how all > the AT_ flags were added to the end for the statat calls. > > > AT_FORCE_ATTR_SYNC can be set in flags.  This will require a network > > filesystem to synchronise its attributes with the server. > > > > AT_NO_ATTR_SYNC can be set in flags.  This will suppress synchronisation > > with the server in a network filesystem.  The resulting values should be > > considered approximate. > > And what happens if neither is set? > I'd suggest we have the documentation state that the lack of either flag leaves it up to the filesystem. In the case of NFS, you'd get "normal" attribute cache behavior, for instance which is governed by the ac* attributes. We should also note that in the case of something like AT_NO_ATTR_SYNC on NFS, you might _still_ end up talking to the server if the client has nothing in-core for that inode. > > 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(). > > No a very good name for the constant.  I don't really see how this macro > is useful to start with.  And _ALL? sure, but what's basic? > > > buffer points to the destination for the data.  This must be 256 bytes in > > size. > > 256 bytes or sizeof(struct statx)?  Even if they end up the same the > latter is a much more useful value. > ACK. We should also consider that while we have a fair bit of padding in this structure now, we could end up running out of space in it at some point. We should at least have a clear idea of how we'll handle such a situation. The obvious solution would be to add a new flag that says that we're passing in an extended statx structure. The kernel would know not to touch stuff in the extended part unless the flag was set. Userland would know that that part had not been touched by the kernel if the outbound flag wasn't set. > > where st_information is local system information about the file, > > What the heck is "local system information"?  Please define each > newly added field in detail. > > > st_gen is > > the inode generation number, st_btime is the file creation time, st_version > > is the data version number (i_version), > > Please define semantics for st_gen and st_version. > > > 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 should also be negative if not zero. > > Please coordinate with Arnd on the timespamp format - I'd hate to have > a different encoding than he plans for all y2028/64-bit-time_t syscalls > to be added soon. > > > STATX_MTIME Want/got st_mtime > > STATX_CTIME Want/got st_ctime > > STATX_INO Want/got st_ino > > STATX_SIZE Want/got st_size > > STATX_BLOCKS Want/got st_blocks > > STATX_BASIC_STATS [The stuff in the normal stat struct] > > STATX_BTIME Want/got st_btime > > STATX_VERSION Want/got st_data_version > > What is st_data_version? > > > STATX_GEN Want/got st_gen > > STATX_ALL_STATS [All currently available stuff] > > Where does the STATS_ come from?  Why no simply _ALL? > > How are the semantics defined when userspace asks for fields not > available?  I'd expect them to be ignored, but we should documentat that > fact. > > > The defined bits in the st_information field give local system data on a > > file, how it is accessed, where it is and what it does: > > Oh, here we get st_information.  The name sounds very wrong for these > flags, though. > > > STATX_INFO_ENCRYPTED File is encrypted > > How do you define "encrypted", and what can the user do with this > information? > > > STATX_INFO_TEMPORARY File is temporary > > How do you define "temporary", and what can the user do with this > information? > > > STATX_INFO_FABRICATED File was made up by filesystem > > How do you define "fabricated", and what can the user do with this > information? > > > STATX_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs) > > How do you define "kernel API" and what can the user do with this > information? > > > STATX_INFO_REMOTE File is remote > > How do you define "remote" and what can the user do with this > information? > > > STATX_INFO_AUTOMOUNT Dir is automount trigger > > How do you define "automount trigger" and what can the user do with this > information? > > > STATX_INFO_AUTODIR Dir provides unlisted automounts > > How do you define "unlisted automount" and what can the user do with this > information? > > > STATX_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details > > How do you define "non-system ownership" and what can the user do with this > information? > Good questions all around. My personal opinion is that if we have any attrs that are of questionable value or that don't have a clear definition, that we should just leave them out for now. This interface is designed to be extendable, so there's no need to add it all in in the first pass. We should focus on getting the API right and sort out the gory details of specific attributes on a case-by-case basis. > > > > These are for the use of GUI tools that might want to mark files specially, > > depending on what they are. > > So far I don't see good definition of either flag, nor a good reason > to add. > > > Fields in struct statx come in a number of classes: > > I really disagree with all these special cases.  You should get > what you ask for, or rather what you ask for IFF the fs can provide it. > And we need to document for each field if it's optional if we want > to treat it as option.  A hodge podge bag of special cases is not an > API that a normal person can use. > Agreed. In fact, the required attributes might be a good place to draw the line on the initial submission of this patchset. Maybe just say "no optional attributes yet" and we'll add them in later patches? > > The following test program can be used to test the statx system call: > > > > samples/statx/test-statx.c > > Please add xfstests test cases that test all the corner cases. > > And please prepare a man page to document this system call properly. Nothing wrong with preparing that ahead of time, but I see that as something that should go along with the userland submission. In fact, what's the plan for userland here? Should this be added to glibc or do would it be better/simpler to have a new library for this? Either way, what would be best for now though is to do What Neil suggested, and lift most of this commit log into a file under Documentation/. Furthermore, it'd probably be nice to document each mask bit in the header file that userland will end up including. It's often the case that the manpage may not reflect what the currently installed kernel actually supports. The kernel headers are often more authoritative. Being able to look at the header file for would be ideal.
Christoph Hellwig <hch@infradead.org> wrote: > > int ret = statx(int dfd, > > const char *filename, > > unsigned int flags, > > unsigned int mask, > > struct statx *buffer); > > Please move the flags and mask after the buffer, similar to how all > the AT_ flags were added to the end for the statat calls. Sure, if you really want. > > AT_FORCE_ATTR_SYNC can be set in flags. This will require a network > > filesystem to synchronise its attributes with the server. > > > > AT_NO_ATTR_SYNC can be set in flags. This will suppress synchronisation > > with the server in a network filesystem. The resulting values should be > > considered approximate. > > And what happens if neither is set? It does what stat() does now, whatever that is for each fs. The assumption is that this might be used to emulate stat() from userspace. However, we want to be able to make sure we get the two behaviours above. > > 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(). > > No a very good name for the constant. I don't really see how this macro > is useful to start with. It's the bits that correspond to all the data in the the current stat struct. So if you want to emulate stat(), you should pass this in mask. > And _ALL? sure, but what's basic? Actually, _ALL is perhaps the less useful of the two since the bitset is not closed. OTOH - anything not in _ALL won't be listed explicitly in the structure, but would rather consume space space. > > st_gen is > > the inode generation number, st_btime is the file creation time, st_version > > is the data version number (i_version), > > Please define semantics for st_gen and st_version. I've been asked to drop st_gen for security reasons. I can't offhand think of a way to define st_version (or i_version, for that matter) that would be consistent across all filesystems. I would lean towards "gets incremented monotonically by 1 for each data write operation committed, but not for any metadata operations", but I'm fairly certain this won't jibe with disk operations. So I can leave it out for now and bring it back if we find a real user for it. > > 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 should also be negative if not zero. > > Please coordinate with Arnd on the timespamp format - I'd hate to have > a different encoding than he plans for all y2028/64-bit-time_t syscalls > to be added soon. I have discussed this with him previously. > > STATX_VERSION Want/got st_data_version > > What is st_data_version? Sorry, that should've been st_version. It got renamed. > > STATX_GEN Want/got st_gen > > STATX_ALL_STATS [All currently available stuff] > > Where does the STATS_ come from? Why no simply _ALL? Why not STATX_ALL_STATS? 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
David Howells <dhowells@redhat.com> wrote: > > > st_gen is > > > the inode generation number, st_btime is the file creation time, st_version > > > is the data version number (i_version), > > > > Please define semantics for st_gen and st_version. > > I've been asked to drop st_gen for security reasons. > > I can't offhand think of a way to define st_version (or i_version, for that > matter) that would be consistent across all filesystems. I would lean towards > "gets incremented monotonically by 1 for each data write operation committed, > but not for any metadata operations", but I'm fairly certain this won't jibe > with disk operations. I meant disk filesystems that we have now, not disk operations. 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
DQoNCg0KDQoNCk9uIDUvOS8xNiwgMDg6NTcsICJsaW51eC1uZnMtb3duZXJAdmdlci5rZXJuZWwu b3JnIG9uIGJlaGFsZiBvZiBEYXZpZCBIb3dlbGxzIiA8bGludXgtbmZzLW93bmVyQHZnZXIua2Vy bmVsLm9yZyBvbiBiZWhhbGYgb2YgZGhvd2VsbHNAcmVkaGF0LmNvbT4gd3JvdGU6DQoNCj5DaHJp c3RvcGggSGVsbHdpZyA8aGNoQGluZnJhZGVhZC5vcmc+IHdyb3RlOg0KPg0KPj4gPiAJaW50IHJl dCA9IHN0YXR4KGludCBkZmQsDQo+PiA+IAkJCWNvbnN0IGNoYXIgKmZpbGVuYW1lLA0KPj4gPiAJ CQl1bnNpZ25lZCBpbnQgZmxhZ3MsDQo+PiA+IAkJCXVuc2lnbmVkIGludCBtYXNrLA0KPj4gPiAJ CQlzdHJ1Y3Qgc3RhdHggKmJ1ZmZlcik7DQo+PiANCj4+IFBsZWFzZSBtb3ZlIHRoZSBmbGFncyBh bmQgbWFzayBhZnRlciB0aGUgYnVmZmVyLCBzaW1pbGFyIHRvIGhvdyBhbGwNCj4+IHRoZSBBVF8g ZmxhZ3Mgd2VyZSBhZGRlZCB0byB0aGUgZW5kIGZvciB0aGUgc3RhdGF0IGNhbGxzLg0KPg0KPlN1 cmUsIGlmIHlvdSByZWFsbHkgd2FudC4NCj4NCj4+ID4gQVRfRk9SQ0VfQVRUUl9TWU5DIGNhbiBi ZSBzZXQgaW4gZmxhZ3MuICBUaGlzIHdpbGwgcmVxdWlyZSBhIG5ldHdvcmsNCj4+ID4gZmlsZXN5 c3RlbSB0byBzeW5jaHJvbmlzZSBpdHMgYXR0cmlidXRlcyB3aXRoIHRoZSBzZXJ2ZXIuDQo+PiA+ IA0KPj4gPiBBVF9OT19BVFRSX1NZTkMgY2FuIGJlIHNldCBpbiBmbGFncy4gIFRoaXMgd2lsbCBz dXBwcmVzcyBzeW5jaHJvbmlzYXRpb24NCj4+ID4gd2l0aCB0aGUgc2VydmVyIGluIGEgbmV0d29y ayBmaWxlc3lzdGVtLiAgVGhlIHJlc3VsdGluZyB2YWx1ZXMgc2hvdWxkIGJlDQo+PiA+IGNvbnNp ZGVyZWQgYXBwcm94aW1hdGUuDQo+PiANCj4+IEFuZCB3aGF0IGhhcHBlbnMgaWYgbmVpdGhlciBp cyBzZXQ/DQo+DQo+SXQgZG9lcyB3aGF0IHN0YXQoKSBkb2VzIG5vdywgd2hhdGV2ZXIgdGhhdCBp cyBmb3IgZWFjaCBmcy4gIFRoZSBhc3N1bXB0aW9uIGlzDQo+dGhhdCB0aGlzIG1pZ2h0IGJlIHVz ZWQgdG8gZW11bGF0ZSBzdGF0KCkgZnJvbSB1c2Vyc3BhY2UuICBIb3dldmVyLCB3ZSB3YW50IHRv DQo+YmUgYWJsZSB0byBtYWtlIHN1cmUgd2UgZ2V0IHRoZSB0d28gYmVoYXZpb3VycyBhYm92ZS4N Cj4NCj4+ID4gbWFzayBpcyBhIGJpdG1hc2sgaW5kaWNhdGluZyB0aGUgZmllbGRzIGluIHN0cnVj dCBzdGF0eCB0aGF0IGFyZSBvZg0KPj4gPiBpbnRlcmVzdCB0byB0aGUgY2FsbGVyLiAgVGhlIHVz ZXIgc2hvdWxkIHNldCB0aGlzIHRvIFNUQVRYX0JBU0lDX1NUQVRTIHRvDQo+PiA+IGdldCB0aGUg YmFzaWMgc2V0IHJldHVybmVkIGJ5IHN0YXQoKS4NCj4+IA0KPj4gTm8gYSB2ZXJ5IGdvb2QgbmFt ZSBmb3IgdGhlIGNvbnN0YW50LiAgSSBkb24ndCByZWFsbHkgc2VlIGhvdyB0aGlzIG1hY3JvDQo+ PiBpcyB1c2VmdWwgdG8gc3RhcnQgd2l0aC4NCj4NCj5JdCdzIHRoZSBiaXRzIHRoYXQgY29ycmVz cG9uZCB0byBhbGwgdGhlIGRhdGEgaW4gdGhlIHRoZSBjdXJyZW50IHN0YXQgc3RydWN0Lg0KPlNv IGlmIHlvdSB3YW50IHRvIGVtdWxhdGUgc3RhdCgpLCB5b3Ugc2hvdWxkIHBhc3MgdGhpcyBpbiBt YXNrLg0KPg0KPj4gQW5kIF9BTEw/IHN1cmUsIGJ1dCB3aGF0J3MgYmFzaWM/DQo+DQo+QWN0dWFs bHksIF9BTEwgaXMgcGVyaGFwcyB0aGUgbGVzcyB1c2VmdWwgb2YgdGhlIHR3byBzaW5jZSB0aGUg Yml0c2V0IGlzIG5vdA0KPmNsb3NlZC4gIE9UT0ggLSBhbnl0aGluZyBub3QgaW4gX0FMTCB3b24n dCBiZSBsaXN0ZWQgZXhwbGljaXRseSBpbiB0aGUNCj5zdHJ1Y3R1cmUsIGJ1dCB3b3VsZCByYXRo ZXIgY29uc3VtZSBzcGFjZSBzcGFjZS4NCj4NCj4+ID4gc3RfZ2VuIGlzDQo+PiA+IHRoZSBpbm9k ZSBnZW5lcmF0aW9uIG51bWJlciwgc3RfYnRpbWUgaXMgdGhlIGZpbGUgY3JlYXRpb24gdGltZSwg c3RfdmVyc2lvbg0KPj4gPiBpcyB0aGUgZGF0YSB2ZXJzaW9uIG51bWJlciAoaV92ZXJzaW9uKSwN Cj4+IA0KPj4gUGxlYXNlIGRlZmluZSBzZW1hbnRpY3MgZm9yIHN0X2dlbiBhbmQgc3RfdmVyc2lv bi4NCj4NCj5JJ3ZlIGJlZW4gYXNrZWQgdG8gZHJvcCBzdF9nZW4gZm9yIHNlY3VyaXR5IHJlYXNv bnMuDQo+DQo+SSBjYW4ndCBvZmZoYW5kIHRoaW5rIG9mIGEgd2F5IHRvIGRlZmluZSBzdF92ZXJz aW9uIChvciBpX3ZlcnNpb24sIGZvciB0aGF0DQo+bWF0dGVyKSB0aGF0IHdvdWxkIGJlIGNvbnNp c3RlbnQgYWNyb3NzIGFsbCBmaWxlc3lzdGVtcy4gIEkgd291bGQgbGVhbiB0b3dhcmRzDQo+Imdl dHMgaW5jcmVtZW50ZWQgbW9ub3RvbmljYWxseSBieSAxIGZvciBlYWNoIGRhdGEgd3JpdGUgb3Bl cmF0aW9uIGNvbW1pdHRlZCwNCj5idXQgbm90IGZvciBhbnkgbWV0YWRhdGEgb3BlcmF0aW9ucyIs IGJ1dCBJJ20gZmFpcmx5IGNlcnRhaW4gdGhpcyB3b24ndCBqaWJlDQo+d2l0aCBkaXNrIG9wZXJh dGlvbnMuICBTbyBJIGNhbiBsZWF2ZSBpdCBvdXQgZm9yIG5vdyBhbmQgYnJpbmcgaXQgYmFjayBp ZiB3ZQ0KPmZpbmQgYSByZWFsIHVzZXIgZm9yIGl0Lg0KDQpUaGUgTkZTdjQgZGVmaW5pdGlvbiBm b3IgdGhlIGNoYW5nZSBhdHRyaWJ1dGUgKHdoaWNoIGlzIG1hcHBlZCB0byBpX3ZlcnNpb24gd2hl biBJU19JX1ZFUlNJT04oaW5vZGUpIGlzIHRydWUpIGlzDQoNCiJBIHZhbHVlIGNyZWF0ZWQgYnkg dGhlIHNlcnZlciB0aGF0IHRoZSBjbGllbnQgY2FuIHVzZSB0byBkZXRlcm1pbmUgaWYNCiAgIGZp bGUgZGF0YSwgZGlyZWN0b3J5IGNvbnRlbnRzLCBvciBhdHRyaWJ1dGVzIG9mIHRoZSBvYmplY3Qg aGF2ZSBiZWVuDQogICBtb2RpZmllZC4gIFRoZSBzZXJ2ZXIgbWF5IHJldHVybiB0aGUgb2JqZWN0 J3MgdGltZV9tZXRhZGF0YSBhdHRyaWJ1dGUNCiAgIGZvciB0aGlzIGF0dHJpYnV0ZSdzIHZhbHVl LCBidXQgb25seSBpZiB0aGUgZmlsZSBzeXN0ZW0gb2JqZWN0IGNhbm5vdA0KICAgYmUgdXBkYXRl ZCBtb3JlIGZyZXF1ZW50bHkgdGhhbiB0aGUgcmVzb2x1dGlvbiBvZiB0aW1lX21ldGFkYXRhLiIN Cg0KDQpJT1c6IGl0IGlzIGEgdmFsdWUgdGhhdCBjaGFuZ2VzIG9uIGFsbCBkYXRhIGFuZCBtZXRh ZGF0YSBvcGVyYXRpb25zLCBhbmQgd2l0aCBubyBtb25vdG9uaWNpdHkgcmVxdWlyZW1lbnQuIEni gJltIHByZXR0eSBzdXJlIGFsbCB1c2Vyc3BhY2UgTkZTdjQgc2VydmVycyBvdXQgdGhlcmUgd291 bGQgbGlrZSB0byBhY2Nlc3MgaXQgKGUuZy4gR2FuZXNoYSwgZENhY2hlKS4NCg0KPg0KPj4gPiBU aW1lIGZpZWxkcyBhcmUgc3BsaXQgaW50byBzZXBhcmF0ZSBzZWNvbmRzIGFuZCBuYW5vc2Vjb25k cyBmaWVsZHMgdG8gbWFrZQ0KPj4gPiBwYWNraW5nIGVhc2llciBhbmQgdGhlIGdyYW51bGFyaXRp ZXMgY2FuIGJlIHF1ZXJpZWQgd2l0aCB0aGUgZmlsZXN5c3RlbQ0KPj4gPiBpbmZvIHN5c3RlbSBj YWxsLiAgTm90ZSB0aGF0IHRpbWVzIHdpbGwgYmUgbmVnYXRpdmUgaWYgYmVmb3JlIDE5NzA7IGlu IHN1Y2gNCj4+ID4gYSBjYXNlLCB0aGUgbmFub3NlY29uZCBmaWVsZHMgc2hvdWxkIGFsc28gYmUg bmVnYXRpdmUgaWYgbm90IHplcm8uDQo+PiANCj4+IFBsZWFzZSBjb29yZGluYXRlIHdpdGggQXJu ZCBvbiB0aGUgdGltZXNwYW1wIGZvcm1hdCAtIEknZCBoYXRlIHRvIGhhdmUNCj4+IGEgZGlmZmVy ZW50IGVuY29kaW5nIHRoYW4gaGUgcGxhbnMgZm9yIGFsbCB5MjAyOC82NC1iaXQtdGltZV90IHN5 c2NhbGxzDQo+PiB0byBiZSBhZGRlZCBzb29uLg0KPg0KPkkgaGF2ZSBkaXNjdXNzZWQgdGhpcyB3 aXRoIGhpbSBwcmV2aW91c2x5Lg0KPg0KPj4gPiAJU1RBVFhfVkVSU0lPTgkJV2FudC9nb3Qgc3Rf ZGF0YV92ZXJzaW9uDQo+PiANCj4+IFdoYXQgaXMgc3RfZGF0YV92ZXJzaW9uPw0KPg0KPlNvcnJ5 LCB0aGF0IHNob3VsZCd2ZSBiZWVuIHN0X3ZlcnNpb24uICBJdCBnb3QgcmVuYW1lZC4NCj4NCj4+ ID4gCVNUQVRYX0dFTgkJV2FudC9nb3Qgc3RfZ2VuDQo+PiA+IAlTVEFUWF9BTExfU1RBVFMJCVtB bGwgY3VycmVudGx5IGF2YWlsYWJsZSBzdHVmZl0NCj4+IA0KPj4gV2hlcmUgZG9lcyB0aGUgU1RB VFNfIGNvbWUgZnJvbT8gIFdoeSBubyBzaW1wbHkgX0FMTD8NCj4NCj5XaHkgbm90IFNUQVRYX0FM TF9TVEFUUz8NCj4NCj5EYXZpZA0KPi0tDQo+VG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6 IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LW5mcyIgaW4NCj50aGUgYm9keSBvZiBh IG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZw0KPk1vcmUgbWFqb3Jkb21vIGlu Zm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0KPg0K -- 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
Christoph Hellwig <hch@infradead.org> wrote: > How are the semantics defined when userspace asks for fields not > available? I'd expect them to be ignored, but we should documentat that > fact. I went into this in some detail. > > Fields in struct statx come in a number of classes: > > I really disagree with all these special cases. You should get > what you ask for, or rather what you ask for IFF the fs can provide it. > And we need to document for each field if it's optional if we want > to treat it as option. I did document this. You saw it as a bunch of special cases. It is not. stat() fabricates some of the data it returns under certain circumstances. > A hodge podge bag of special cases is not an API that a normal person can > use. Let's look at the list, and please bear in mind I'm trying to make it so that you can emulate stat() through this interface. If you want to waive that requirement - or push the emulation out to userspace - then I can forego providing unsupported data from the basic stat set. | (0) st_information, st_dev_*, st_blksize. st_dev_* and st_blksize must always be available from whatever we stat. Because this is the case, there's no point providing mask bits for them. My implementation defines st_information to be in this class, but it doesn't have to be. Note that st_information really needs a way to ask the filesystem what flags it actually supports so that you can distinguish being 0 -> not set from 0 -> not supported, hence the fsinfo() interface that I've dropped for now. | (1) st_nlinks, st_uid, st_gid, st_[amc]time*, st_ino, st_size, st_blocks. These data are all in the bog standard struct stat. As it is, they must all be given values as for stat(). However, mask bits are provided to indicate when the value presented here is actually fabricated so that the user can decide not to use them. | (2) st_mode. This is actually in two parts. There's the file type (which must always be set correctly) and the mode bits (which may be fabricated). STATX_MODE covers the mode bits only. | (3) st_rdev_*. This datum is part of the bog standard struct stat, and as such must be set to something. However, the value is only relevant in the case that the mode indicates a blockdev or chardev. STATX_RDEV can be considered redundant in such a case. | (4) File creation time (st_btime*), data version (st_version), inode | generation number (st_gen). These are all new data and have no counterpart in the Linux struct stat. However, they do in the struct stat on other Unix variants (st_birthtime and st_gen, for example, exist on BSD). Not all filesystems provide them so if they are requested but are not actually supported by a filesystem, the bit in the mask is cleared upon returning. However, even if you didn't ask for a datum, it may still be available - and I am permitting a filesystem to give you the datum and mark the mask to indicate the value's availability, even if you didn't ask for it. You are free to ignore it. At this time, I think it likely that all new attributes would be in this class. One could argue that something like st_win_attrs (in patch 5) could be in class 0 if added immediately, but anything added later *must* have a mask bit to indicate its presence. So, barring st_information, classes (0) - (3) are all current stat stuff. That is how they work *now*. All I'm doing is defining which data have mask bits, and under what conditions the mask bit might not be set. 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
Christoph Hellwig <hch@infradead.org> wrote:
> And please prepare a man page to document this system call properly.
I intend to - but when it's stabilised sufficiently to warrant inclusion.
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
On Mon, May 09, 2016 at 08:02:58AM -0400, Jeff Layton wrote: > > > AT_FORCE_ATTR_SYNC can be set in flags.????This will require a network > > > filesystem to synchronise its attributes with the server. > > > > > > AT_NO_ATTR_SYNC can be set in flags.????This will suppress synchronisation > > > with the server in a network filesystem.????The resulting values should be > > > considered approximate. > > > > And what happens if neither is set? > > > > I'd suggest we have the documentation state that the lack of either > flag leaves it up to the filesystem. In the case of NFS, you'd get > "normal" attribute cache behavior, for instance which is governed by > the ac* attributes. > > We should also note that in the case of something like AT_NO_ATTR_SYNC > on NFS, you might _still_ end up talking to the server if the client > has nothing in-core for that inode. File systems specific "legacy" defaults are a bad idea. If we can't describe the semantics we should not allow them, never mind making the the default. I'd strongly suggest picking one of the above flags as the default behavior and only allowing the other as optional flag. I suspect NO_SYNC is the better one for the flag, as otherwise people will be surprised once they test their default case on a network filesystem. -- 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
On Mon, May 09, 2016 at 01:57:32PM +0100, David Howells wrote: > > > AT_FORCE_ATTR_SYNC can be set in flags. This will require a network > > > filesystem to synchronise its attributes with the server. > > > > > > AT_NO_ATTR_SYNC can be set in flags. This will suppress synchronisation > > > with the server in a network filesystem. The resulting values should be > > > considered approximate. > > > > And what happens if neither is set? > > It does what stat() does now, whatever that is for each fs. The assumption is > that this might be used to emulate stat() from userspace. However, we want to > be able to make sure we get the two behaviours above. And why would you emulate stat if we already have a perfectly working version of it? Either way we need to document what that behavior is, and why userspace would chose one of the three options. > > > 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(). > > > > No a very good name for the constant. I don't really see how this macro > > is useful to start with. > > It's the bits that correspond to all the data in the the current stat struct. > So if you want to emulate stat(), you should pass this in mask. which of the many stat version supported by Linux or glibc (nevermind other OSes)? And why would you care about that, as you could just use stat in that case? And even if you really cared how do you know what attributes are "basic" if we don't properly document that? And last but not least why would the caller of the syscall (various libcs) care to get this constant instead of defining it on it's own based on what ABI it exports? > > > STATX_GEN Want/got st_gen > > > STATX_ALL_STATS [All currently available stuff] > > > > Where does the STATS_ come from? Why no simply _ALL? > > Why not STATX_ALL_STATS? Because it's the only places STATS or stats is used in the whole interface. It also doesn't match our common use for stats (as in statistics, not fields of a stat-like structure) -- 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
On Mon, May 09, 2016 at 02:38:21PM +0100, David Howells wrote: > Let's look at the list, and please bear in mind I'm trying to make it so that > you can emulate stat() through this interface. If you want to waive that > requirement - or push the emulation out to userspace - then I can forego > providing unsupported data from the basic stat set. why would you want to emulate stat? > | (0) st_information, st_dev_*, st_blksize. > > st_dev_* and st_blksize must always be available from whatever we stat. > Because this is the case, there's no point providing mask bits for them. > > My implementation defines st_information to be in this class, but it doesn't > have to be. Note that st_information really needs a way to ask the filesystem > what flags it actually supports so that you can distinguish being 0 -> not set > from 0 -> not supported, hence the fsinfo() interface that I've dropped for > now. All of these are easily available. But why special case them so that userspace must not ask for them? This makes an otherwise totally regular interface special now. Note that filesystems could always fill it out anyway and set it in the return mask. > | (1) st_nlinks, st_uid, st_gid, st_[amc]time*, st_ino, st_size, st_blocks. > > These data are all in the bog standard struct stat. As it is, they must all > be given values as for stat(). However, mask bits are provided to indicate > when the value presented here is actually fabricated so that the user can > decide not to use them. Next special case.. > | (2) st_mode. > > This is actually in two parts. There's the file type (which must always be > set correctly) and the mode bits (which may be fabricated). STATX_MODE covers > the mode bits only. Next special case. > > | (3) st_rdev_*. > > This datum is part of the bog standard struct stat, and as such must be set to > something. However, the value is only relevant in the case that the mode > indicates a blockdev or chardev. STATX_RDEV can be considered redundant in > such a case. > > | (4) File creation time (st_btime*), data version (st_version), inode > | generation number (st_gen). > > These are all new data and have no counterpart in the Linux struct stat. > However, they do in the struct stat on other Unix variants (st_birthtime and > st_gen, for example, exist on BSD). Not all filesystems provide them so if > they are requested but are not actually supported by a filesystem, the bit in > the mask is cleared upon returning. > > However, even if you didn't ask for a datum, it may still be available - and I > am permitting a filesystem to give you the datum and mark the mask to indicate > the value's availability, even if you didn't ask for it. You are free to > ignore it. I think the fs may return it anyway case is fine, but let's make that a 100% generic thing and not special case fields. > At this time, I think it likely that all new attributes would be in this > class. One could argue that something like st_win_attrs (in patch 5) could be > in class 0 if added immediately, but anything added later *must* have a mask > bit to indicate its presence. > > > So, barring st_information, classes (0) - (3) are all current stat stuff. > That is how they work *now*. All I'm doing is defining which data have mask > bits, and under what conditions the mask bit might not be set. Who cares about stat? You are adding a new system call and are not bound by what certain versions of stat did at specific points in time. -- 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
Christoph Hellwig <hch@infradead.org> wrote: > > It does what stat() does now, whatever that is for each fs. The > > assumption is that this might be used to emulate stat() from userspace. > > However, we want to be able to make sure we get the two behaviours above. > > And why would you emulate stat if we already have a perfectly working > version of it? Either way we need to document what that behavior is, > and why userspace would chose one of the three options. Because it's not necessarily a perfectly working version of it. See the Y2037 problem for example. I was assuming that C libraries might want to update the struct stat and the stat call() to provide fields that aren't currently there in Linux but are in other OS's. We could even dispense with older stat syscalls on new arches. Admittedly, this means that you would have backwardly incompatible versions of the C library and would have to version your interface, so it might be too much effort. However, if we're going to discard this possibility, we can make these features available only to direct calls of extended stat. 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
Christoph Hellwig <hch@infradead.org> wrote: > All of these are easily available. But why special case them so that > userspace must not ask for them? This makes an otherwise totally > regular interface special now. Note that filesystems could always fill > it out anyway and set it in the return mask. Because it would be a waste of bits in the mask. Is there a point in having bits that are always going to be set unconditionally when we can just *document* that these few fields are always going to be set. I'm sure people can cope with the concept that some data are provided unconditionally and don't have bits and the rest are provided conditionally and do have bits. I admit, though, that i_mode is tricky, since it's actually the combination of two pieces of information - one conditional (permission bits) and one normally unconditional (file type). Possibly then i_mode should have two flags since I can think of situations where the file type might be other - reparse points, automount points. So yes, you can look on it as there are special cases. However, if I can drop stat emulation support, everything resolves down to the following classes: (1) Stuff that's unconditional: st_dev, st_blksize, st_information (maybe). (2) st_mode & S_IFMT. Unconditional or conditional? I'm not sure. (3) Stuff that's conditional: st_mode & ~S_IFMT, st_rdev, st_ino, ... Basically everything else. 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
On Tue, 2016-05-10 at 00:00 -0700, Christoph Hellwig wrote: > On Mon, May 09, 2016 at 08:02:58AM -0400, Jeff Layton wrote: > > > > AT_FORCE_ATTR_SYNC can be set in flags.????This will require a > > > > network > > > > filesystem to synchronise its attributes with the server. > > > > > > > > AT_NO_ATTR_SYNC can be set in flags.????This will suppress > > > > synchronisation > > > > with the server in a network filesystem.????The resulting > > > > values should be > > > > considered approximate. > > > > > > And what happens if neither is set? > > > > > > > I'd suggest we have the documentation state that the lack of either > > flag leaves it up to the filesystem. In the case of NFS, you'd get > > "normal" attribute cache behavior, for instance which is governed > > by > > the ac* attributes. > > > > We should also note that in the case of something like > > AT_NO_ATTR_SYNC > > on NFS, you might _still_ end up talking to the server if the > > client > > has nothing in-core for that inode. > > File systems specific "legacy" defaults are a bad idea.  If we can't > describe the semantics we should not allow them, never mind making > the the default.  I'd strongly suggest picking one of the above flags > as the default behavior and only allowing the other as optional flag. > I suspect NO_SYNC is the better one for the flag, as otherwise people > will be surprised once they test their default case on a network > filesystem. Ok, that's a good point. So basically you suggest that xstat should always have FORCE_SYNC semantics unless the NO_SYNC flag is set? Given that we don't need to worry about legacy users with this interface, that seems like a reasonable approach to me.
On Tue, May 10, 2016 at 09:25:55AM +0100, David Howells wrote: > Because it's not necessarily a perfectly working version of it. See the Y2037 > problem for example. > > I was assuming that C libraries might want to update the struct stat and the > stat call() to provide fields that aren't currently there in Linux but are in > other OS's. We could even dispense with older stat syscalls on new arches. Please stop this whole let's get rid of old syscalls on new architectures stuff. This just means we have to do the translation multiple, and the one in userspace is more costly as we it needs to be in every copy of the library. And times where we had a single libc instance (nevermind implementation) are long over if we ever actually had them. > However, if we're going to discard this possibility, we can make these > features available only to direct calls of extended stat. And even if we want to to do a stat emulation despite that above argument let's add the flag once a major libc implementation actually wants to use it and taylor it towards the use case. Don't just add it just because, and even more importantly don't make it the default. -- 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
On Tue, May 10, 2016 at 09:43:43AM +0100, David Howells wrote: > Christoph Hellwig <hch@infradead.org> wrote: > > > All of these are easily available. But why special case them so that > > userspace must not ask for them? This makes an otherwise totally > > regular interface special now. Note that filesystems could always fill > > it out anyway and set it in the return mask. > > Because it would be a waste of bits in the mask. Is there a point in having > bits that are always going to be set unconditionally when we can just > *document* that these few fields are always going to be set. And what exaxtly is the cost of these bits? > So yes, you can look on it as there are special cases. However, if I can drop > stat emulation support, everything resolves down to the following classes: > > (1) Stuff that's unconditional: st_dev, st_blksize, st_information (maybe). > > (2) st_mode & S_IFMT. Unconditional or conditional? I'm not sure. > > (3) Stuff that's conditional: st_mode & ~S_IFMT, st_rdev, st_ino, ... > Basically everything else. If we at least go down to one set of conditional and one optional that's at least much better than what we currently have. -- 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
On Thursday 12 May 2016 02:11:41 Christoph Hellwig wrote: > On Tue, May 10, 2016 at 09:25:55AM +0100, David Howells wrote: > > Because it's not necessarily a perfectly working version of it. See the Y2037 > > problem for example. > > > > I was assuming that C libraries might want to update the struct stat and the > > stat call() to provide fields that aren't currently there in Linux but are in > > other OS's. We could even dispense with older stat syscalls on new arches. > > Please stop this whole let's get rid of old syscalls on new > architectures stuff. This just means we have to do the translation > multiple, and the one in userspace is more costly as we it needs to be > in every copy of the library. And times where we had a single libc > instance (nevermind implementation) are long over if we ever actually > had them. I'm trying to understand what that means for the 64-bit time_t syscalls. The patch series I did last year had a replacement 'sys_newfstatat()' syscall but IIRC no other stat variant, the idea being that we would only need to provide this one to the libc and have user space emulate the stat/fstat/lstat/fstatat variants based on that. With the statx introduction, I was hoping to no longer have to add that syscall but instead have libc do everything on top of sys_statx(). Do you think that is reasonable, given that we won't be allowed to call any of the existing stat() variants for a y2038-safe libc build[1], or should we plan to keep needing replacement fstatat (and possibly stat/lstat/fstat) syscalls with 64-bit time_t even after statx() support is merged into the kernel. Arnd [1] the glibc developers plan to allow compatibility for 32-bit time_t and 64-bit time_t in the same binary, but any user space code built with 64-bit time_t must never call into kernel interfaces that use a 32-bit time_t. -- 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
Arnd Bergmann <arnd@arndb.de> wrote: > I'm trying to understand what that means for the 64-bit time_t syscalls. > > The patch series I did last year had a replacement 'sys_newfstatat()' > syscall but IIRC no other stat variant, the idea being that we would > only need to provide this one to the libc and have user space emulate > the stat/fstat/lstat/fstatat variants based on that. > With the statx introduction, I was hoping to no longer have to add > that syscall but instead have libc do everything on top of sys_statx(). > > Do you think that is reasonable, given that we won't be allowed to > call any of the existing stat() variants for a y2038-safe libc build[1], > or should we plan to keep needing replacement fstatat (and possibly > stat/lstat/fstat) syscalls with 64-bit time_t even after statx() support > is merged into the kernel. Christoph? -- 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
On Fri, May 13, 2016 at 05:28:11PM +0200, Arnd Bergmann wrote: > I'm trying to understand what that means for the 64-bit time_t syscalls. > > The patch series I did last year had a replacement 'sys_newfstatat()' > syscall but IIRC no other stat variant, the idea being that we would > only need to provide this one to the libc and have user space emulate > the stat/fstat/lstat/fstatat variants based on that. > With the statx introduction, I was hoping to no longer have to add > that syscall but instead have libc do everything on top of sys_statx(). > > Do you think that is reasonable, given that we won't be allowed to > call any of the existing stat() variants for a y2038-safe libc build[1], > or should we plan to keep needing replacement fstatat (and possibly > stat/lstat/fstat) syscalls with 64-bit time_t even after statx() support > is merged into the kernel. Honestly I think this really matters on the amount of 'emulation' we need - if it's just adding a new flag that can be trivially generated in the syscall stub in userland that's probably fine, but if we have actually differing semantics (like the stat weak attributes) I'd rather have a properly documented syscall. If we otherwise need to rewrite whole structures I'd much rather do that in kernel space. And to get back to stat: if would be really useful to coordinate the new one with glibc so that we don't end up with two different stat structures again like we do for a lot of platforms at the moment. -- 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
Christoph Hellwig <hch@infradead.org> wrote: > Honestly I think this really matters on the amount of 'emulation' we > need - if it's just adding a new flag that can be trivially generated > in the syscall stub in userland that's probably fine, but if we have > actually differing semantics (like the stat weak attributes) I'd rather > have a properly documented syscall. If we otherwise need to rewrite > whole structures I'd much rather do that in kernel space. I very much agree. > And to get back to stat: if would be really useful to coordinate the > new one with glibc so that we don't end up with two different stat > structures again like we do for a lot of platforms at the moment. I've tried reaching out to them and others, but no one responded. 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
========
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_FORCE_ATTR_SYNC can be set in flags. This will require a network
filesystem to synchronise its attributes with the server.
AT_NO_ATTR_SYNC can be set in flags. This will suppress synchronisation
with the server in a network filesystem. The resulting values should be
considered approximate.
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().
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 st_mask;
__u32 st_information;
__u32 st_blksize;
__u32 st_nlink;
__u32 st_gen;
__u32 st_uid;
__u32 st_gid;
__u16 st_mode;
__u16 __spare0[1];
__u64 st_ino;
__u64 st_size;
__u64 st_blocks;
__u64 st_version;
__s64 st_atime;
__s64 st_btime;
__s64 st_ctime;
__s64 st_mtime;
__s32 st_atime_ns;
__s32 st_btime_ns;
__s32 st_ctime_ns;
__s32 st_mtime_ns;
__u32 st_rdev_major;
__u32 st_rdev_minor;
__u32 st_dev_major;
__u32 st_dev_minor;
__u64 __spare1[16];
};
where st_information is local system information about the file, st_gen is
the inode generation number, st_btime is the file creation time, st_version
is the data version number (i_version), st_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 should also be negative if not zero.
The defined bits in request_mask and st_mask are:
STATX_MODE Want/got st_mode
STATX_NLINK Want/got st_nlink
STATX_UID Want/got st_uid
STATX_GID Want/got st_gid
STATX_RDEV Want/got st_rdev_*
STATX_ATIME Want/got st_atime
STATX_MTIME Want/got st_mtime
STATX_CTIME Want/got st_ctime
STATX_INO Want/got st_ino
STATX_SIZE Want/got st_size
STATX_BLOCKS Want/got st_blocks
STATX_BASIC_STATS [The stuff in the normal stat struct]
STATX_BTIME Want/got st_btime
STATX_VERSION Want/got st_data_version
STATX_GEN Want/got st_gen
STATX_ALL_STATS [All currently available stuff]
The defined bits in the st_information field give local system data on a
file, how it is accessed, where it is and what it does:
STATX_INFO_ENCRYPTED File is encrypted
STATX_INFO_TEMPORARY File is temporary
STATX_INFO_FABRICATED File was made up by filesystem
STATX_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs)
STATX_INFO_REMOTE File is remote
STATX_INFO_AUTOMOUNT Dir is automount trigger
STATX_INFO_AUTODIR Dir provides unlisted automounts
STATX_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details
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) st_information, st_dev_*, st_blksize.
These are local data and are always available.
(1) st_nlinks, st_uid, st_gid, st_[amc]time*, st_ino, st_size, st_blocks.
These will be returned whether the caller asks for them or not. The
corresponding bits in st_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 st_mask,
even if the caller asked for the value. In such a case, the returned
value will be a fabrication.
(2) st_mode.
The part of this that identifies the file type will always be
available, irrespective of the setting of STATX_MODE. The access
flags and sticky bit are as for class (1).
(3) st_rdev_*.
As for class (1), but this will be cleared if the file is not a
blockdev or chardev. The bit will be cleared if the value is not
returned.
(4) File creation time (st_btime*), data version (st_version), inode
generation number (st_gen).
These will be returned if available whether the caller asked for them or
not. The corresponding bits in st_mask will be set or cleared as
appropriate to indicate a valid value.
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.
=======
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=4fef
Size: 4096 Blocks: 8 IO Block: 1048576 directory
Device: 00:1d Inode: 2 Links: 110
Access: (3777/drwxrwxrwx) Uid: -2
Gid: 4294967294
Access: 2012-04-30 09:01:55.283819565+0100
Modify: 2012-03-28 19:01:19.405465361+0100
Change: 2012-03-28 19:01:19.405465361+0100
Data version: ef51734f11e92a18h
Information: 00000134 (-------- -------- -------a --mr-f--)
Secondly, the result of automounting on that directory.
[root@andromeda tmp]# ./samples/statx/test-statx /warthog/data
statx(/warthog/data) = 0
results=14fef
Size: 4096 Blocks: 8 IO Block: 1048576 directory
Device: 00:1e Inode: 2 Links: 110
Access: (3777/drwxrwxrwx) Uid: -2
Gid: 4294967294
Access: 2012-04-30 09:01:55.283819565+0100
Modify: 2012-03-28 19:01:19.405465361+0100
Change: 2012-03-28 19:01:19.405465361+0100
Data version: ef51734f11e92a18h
Information: 00000110 (-------- -------- -------a ---r----)
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 | 303 +++++++++++++++++++++++++++++---
include/linux/fs.h | 5 -
include/linux/stat.h | 15 +-
include/linux/syscalls.h | 4
include/uapi/linux/fcntl.h | 2
include/uapi/linux/stat.h | 109 ++++++++++++
samples/Makefile | 2
samples/statx/Makefile | 10 +
samples/statx/test-statx.c | 243 ++++++++++++++++++++++++++
12 files changed, 662 insertions(+), 37 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 b30dd8154cc2..b99a6b3a167c 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -386,3 +386,4 @@
377 i386 copy_file_range sys_copy_file_range
378 i386 preadv2 sys_preadv2
379 i386 pwritev2 sys_pwritev2
+380 i386 statx sys_statx
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
index cac6d17ce5db..6d5ef6c87cdc 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -335,6 +335,7 @@
326 common copy_file_range sys_copy_file_range
327 64 preadv2 sys_preadv2
328 64 pwritev2 sys_pwritev2
+329 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 c46f1a190b8d..cd6d9cbc9300 100644
--- a/fs/exportfs/expfs.c
+++ b/fs/exportfs/expfs.c
@@ -295,7 +295,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..c2f8370dab13 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,197 @@ 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 & ~STATX_RDEV;
+ if (IS_NOATIME(inode))
+ stat->result_mask &= ~STATX_ATIME;
+ else
+ stat->atime = inode->i_atime;
+
+ if (S_ISREG(stat->mode) && stat->nlink == 0)
+ stat->information |= STATX_INFO_TEMPORARY;
+ if (IS_AUTOMOUNT(inode))
+ stat->information |= STATX_INFO_AUTOMOUNT;
+
+ if (unlikely(S_ISBLK(stat->mode) || S_ISCHR(stat->mode)))
+ stat->result_mask |= STATX_RDEV;
+}
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;
+ if ((stat->query_flags & AT_FORCE_ATTR_SYNC) &&
+ (stat->query_flags & AT_NO_ATTR_SYNC))
+ return -EINVAL;
+
+ stat->result_mask = 0;
+ stat->information = 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 +235,65 @@ retry:
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 +308,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 +333,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 +610,80 @@ 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->st_mask ) ||
+ __put_user(stat->mode, &buffer->st_mode ) ||
+ __clear_user(&buffer->__spare0, sizeof(buffer->__spare0)) ||
+ __put_user(stat->nlink, &buffer->st_nlink ) ||
+ __put_user(uid, &buffer->st_uid ) ||
+ __put_user(gid, &buffer->st_gid ) ||
+ __put_user(stat->information, &buffer->st_information ) ||
+ __put_user(stat->blksize, &buffer->st_blksize ) ||
+ __put_user(MAJOR(stat->rdev), &buffer->st_rdev_major ) ||
+ __put_user(MINOR(stat->rdev), &buffer->st_rdev_minor ) ||
+ __put_user(MAJOR(stat->dev), &buffer->st_dev_major ) ||
+ __put_user(MINOR(stat->dev), &buffer->st_dev_minor ) ||
+ __put_timestamp(stat->atime, &buffer->st_atime ) ||
+ __put_timestamp(stat->btime, &buffer->st_btime ) ||
+ __put_timestamp(stat->ctime, &buffer->st_ctime ) ||
+ __put_timestamp(stat->mtime, &buffer->st_mtime ) ||
+ __put_user(stat->ino, &buffer->st_ino ) ||
+ __put_user(stat->size, &buffer->st_size ) ||
+ __put_user(stat->blocks, &buffer->st_blocks ) ||
+ __put_user(stat->version, &buffer->st_version ) ||
+ __put_user(stat->gen, &buffer->st_gen ) ||
+ __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_STATS;
+
+ 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 70e61b58baaf..8b2f6df924e9 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2827,8 +2827,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);
@@ -2845,6 +2846,8 @@ extern int vfs_stat(const char __user *, struct kstat *);
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 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..4f1902b0cb94 100644
--- a/include/linux/stat.h
+++ b/include/linux/stat.h
@@ -19,6 +19,13 @@
#include <linux/uidgid.h>
struct kstat {
+ u32 query_flags; /* Operational flags */
+#define KSTAT_QUERY_FLAGS (AT_FORCE_ATTR_SYNC | AT_NO_ATTR_SYNC)
+ u32 request_mask; /* What fields the user asked for */
+ u32 result_mask; /* What fields the user got */
+ u32 information;
+ u32 win_attrs; /* Windows file attributes */
+ u32 gen;
u64 ino;
dev_t dev;
umode_t mode;
@@ -27,11 +34,13 @@ struct kstat {
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 */
+ uint32_t blksize; /* Preferred I/O size */
+ u64 blocks;
+ u64 version; /* Data version */
};
#endif
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index d795472c54d8..f6bfbf74e44d 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;
@@ -898,4 +899,7 @@ asmlinkage long sys_copy_file_range(int fd_in, loff_t __user *off_in,
asmlinkage long sys_mlock2(unsigned long start, size_t len, int flags);
+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..5c8143b04ff7 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_FORCE_ATTR_SYNC 0x2000 /* Force the attributes to be sync'd with the server */
+#define AT_NO_ATTR_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..55ce6607dab6 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,113 @@
#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 available at all, the field and the bit will both be
+ * cleared;
+ *
+ * - otherwise, if explicitly requested:
+ *
+ * - the datum will be synchronised to the server if AT_FORCE_ATTR_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 st_mask; /* What results were written [uncond] */
+ __u32 st_information; /* Information about the file [uncond] */
+ __u32 st_blksize; /* Preferred general I/O size [uncond] */
+ __u32 st_nlink; /* Number of hard links */
+ /* 0x10 */
+ __u32 st_gen; /* Inode generation number */
+ __u32 st_uid; /* User ID of owner */
+ __u32 st_gid; /* Group ID of owner */
+ __u16 st_mode; /* File mode */
+ __u16 __spare0[1];
+ /* 0x20 */
+ __u64 st_ino; /* Inode number */
+ __u64 st_size; /* File size */
+ __u64 st_blocks; /* Number of 512-byte blocks allocated */
+ __u64 st_version; /* Data version number */
+ /* 0x40 */
+ __s64 st_atime_s; /* Last access time */
+ __s64 st_btime_s; /* File creation time */
+ __s64 st_ctime_s; /* Last attribute change time */
+ __s64 st_mtime_s; /* Last data modification time */
+ /* 0x60 */
+ __s32 st_atime_ns; /* Last access time (ns part) */
+ __s32 st_btime_ns; /* File creation time (ns part) */
+ __s32 st_ctime_ns; /* Last attribute change time (ns part) */
+ __s32 st_mtime_ns; /* Last data modification time (ns part) */
+ /* 0x70 */
+ __u32 st_rdev_major; /* Device ID of special file */
+ __u32 st_rdev_minor;
+ __u32 st_dev_major; /* ID of device containing file [uncond] */
+ __u32 st_dev_minor;
+ /* 0x80 */
+ __u64 __spare1[16]; /* Spare space for future expansion */
+ /* 0x100 */
+};
+
+/*
+ * Flags to be st_mask
+ *
+ * Query request/result mask for statx() and struct statx::st_mask.
+ *
+ * These bits should be set in the mask argument of statx() to request
+ * particular items when calling statx().
+ */
+#define STATX_MODE 0x00000001U /* Want/got st_mode */
+#define STATX_NLINK 0x00000002U /* Want/got st_nlink */
+#define STATX_UID 0x00000004U /* Want/got st_uid */
+#define STATX_GID 0x00000008U /* Want/got st_gid */
+#define STATX_RDEV 0x00000010U /* Want/got st_rdev */
+#define STATX_ATIME 0x00000020U /* Want/got st_atime */
+#define STATX_MTIME 0x00000040U /* Want/got st_mtime */
+#define STATX_CTIME 0x00000080U /* Want/got st_ctime */
+#define STATX_INO 0x00000100U /* Want/got st_ino */
+#define STATX_SIZE 0x00000200U /* Want/got st_size */
+#define STATX_BLOCKS 0x00000400U /* Want/got st_blocks */
+#define STATX_BASIC_STATS 0x000007ffU /* The stuff in the normal stat struct */
+#define STATX_BTIME 0x00000800U /* Want/got st_btime */
+#define STATX_VERSION 0x00001000U /* Want/got st_version */
+#define STATX_GEN 0x00002000U /* Want/got st_gen */
+#define STATX_ALL_STATS 0x00003fffU /* All supported stats */
+
+/*
+ * Flags to be found in st_information
+ *
+ * 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.
+ */
+#define STATX_INFO_ENCRYPTED 0x00000001U /* File is encrypted */
+#define STATX_INFO_TEMPORARY 0x00000002U /* File is temporary */
+#define STATX_INFO_FABRICATED 0x00000004U /* File was made up by filesystem */
+#define STATX_INFO_KERNEL_API 0x00000008U /* File is kernel API (eg: procfs/sysfs) */
+#define STATX_INFO_REMOTE 0x00000010U /* File is remote */
+#define STATX_INFO_AUTOMOUNT 0x00000020U /* Dir is automount trigger */
+#define STATX_INFO_AUTODIR 0x00000040U /* Dir provides unlisted automounts */
+#define STATX_INFO_NONSYSTEM_OWNERSHIP 0x00000080U /* File has non-system ownership details */
#endif /* _UAPI_LINUX_STAT_H */
diff --git a/samples/Makefile b/samples/Makefile
index 48001d7e23f0..d2ebb4e48d19 100644
--- a/samples/Makefile
+++ b/samples/Makefile
@@ -2,4 +2,4 @@
obj-$(CONFIG_SAMPLES) += kobject/ kprobes/ trace_events/ livepatch/ \
hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ \
- configfs/
+ configfs/ statx/
diff --git a/samples/statx/Makefile b/samples/statx/Makefile
new file mode 100644
index 000000000000..6765dabc4c8d
--- /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-y := 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..38ef23c12e7d
--- /dev/null
+++ b/samples/statx/test-statx.c
@@ -0,0 +1,243 @@
+/* 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_FORCE_ATTR_SYNC 0x2000
+#define AT_NO_ATTR_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->st_mask);
+
+ printf(" ");
+ if (stx->st_mask & STATX_SIZE)
+ printf(" Size: %-15llu", (unsigned long long)stx->st_size);
+ if (stx->st_mask & STATX_BLOCKS)
+ printf(" Blocks: %-10llu", (unsigned long long)stx->st_blocks);
+ printf(" IO Block: %-6llu ", (unsigned long long)stx->st_blksize);
+ if (stx->st_mask & STATX_MODE) {
+ switch (stx->st_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->st_mode & S_IFMT);
+ break;
+ }
+ }
+
+ sprintf(buffer, "%02x:%02x", stx->st_dev_major, stx->st_dev_minor);
+ printf("Device: %-15s", buffer);
+ if (stx->st_mask & STATX_INO)
+ printf(" Inode: %-11llu", (unsigned long long) stx->st_ino);
+ if (stx->st_mask & STATX_SIZE)
+ printf(" Links: %-5u", stx->st_nlink);
+ if (stx->st_mask & STATX_RDEV)
+ printf(" Device type: %u,%u", stx->st_rdev_major, stx->st_rdev_minor);
+ printf("\n");
+
+ if (stx->st_mask & STATX_MODE)
+ printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c) ",
+ stx->st_mode & 07777,
+ ft,
+ stx->st_mode & S_IRUSR ? 'r' : '-',
+ stx->st_mode & S_IWUSR ? 'w' : '-',
+ stx->st_mode & S_IXUSR ? 'x' : '-',
+ stx->st_mode & S_IRGRP ? 'r' : '-',
+ stx->st_mode & S_IWGRP ? 'w' : '-',
+ stx->st_mode & S_IXGRP ? 'x' : '-',
+ stx->st_mode & S_IROTH ? 'r' : '-',
+ stx->st_mode & S_IWOTH ? 'w' : '-',
+ stx->st_mode & S_IXOTH ? 'x' : '-');
+ if (stx->st_mask & STATX_UID)
+ printf("Uid: %5d ", stx->st_uid);
+ if (stx->st_mask & STATX_GID)
+ printf("Gid: %5d\n", stx->st_gid);
+
+ if (stx->st_mask & STATX_ATIME)
+ print_time("Access: ", stx->st_atime_s, stx->st_atime_ns);
+ if (stx->st_mask & STATX_MTIME)
+ print_time("Modify: ", stx->st_mtime_s, stx->st_mtime_ns);
+ if (stx->st_mask & STATX_CTIME)
+ print_time("Change: ", stx->st_ctime_s, stx->st_ctime_ns);
+ if (stx->st_mask & STATX_BTIME)
+ print_time(" Birth: ", stx->st_btime_s, stx->st_btime_ns);
+
+ if (stx->st_mask & STATX_VERSION)
+ printf("Data version: %llxh\n",
+ (unsigned long long)stx->st_version);
+
+ if (stx->st_mask & STATX_GEN)
+ printf("Inode gen : %xh\n", stx->st_gen);
+
+ if (stx->st_information) {
+ unsigned char bits;
+ int loop, byte;
+
+ static char info_representation[32 + 1] =
+ /* STATX_INFO_ flags: */
+ "????????" /* 31-24 0x00000000-ff000000 */
+ "????????" /* 23-16 0x00000000-00ff0000 */
+ "????????" /* 15- 8 0x00000000-0000ff00 */
+ "ndmrkfte" /* 7- 0 0x00000000-000000ff */
+ ;
+
+ printf("Information: %08x (", stx->st_information);
+ for (byte = 32 - 8; byte >= 0; byte -= 8) {
+ bits = stx->st_information >> byte;
+ for (loop = 7; loop >= 0; loop--) {
+ int bit = byte + loop;
+
+ if (bits & 0x80)
+ putchar(info_representation[31 - bit]);
+ else
+ putchar('-');
+ bits <<= 1;
+ }
+ if (byte)
+ putchar(' ');
+ }
+ printf(")\n");
+ }
+
+ printf("IO-blocksize: blksize=%u\n", stx->st_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_STATS;
+
+ for (argv++; *argv; argv++) {
+ if (strcmp(*argv, "-F") == 0) {
+ atflag |= AT_FORCE_ATTR_SYNC;
+ continue;
+ }
+ if (strcmp(*argv, "-N") == 0) {
+ atflag |= AT_NO_ATTR_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;
+}