diff mbox

[1/6] statx: Add a system call to make enhanced file info available

Message ID 20160429125743.23636.85219.stgit@warthog.procyon.org.uk (mailing list archive)
State New, archived
Headers show

Commit Message

David Howells April 29, 2016, 12:57 p.m. UTC
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.



--
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

Comments

Andreas Dilger May 2, 2016, 10:46 p.m. UTC | #1
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
David Howells May 3, 2016, 3:53 p.m. UTC | #2
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
Dave Chinner May 4, 2016, 10:56 p.m. UTC | #3
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.
NeilBrown May 4, 2016, 11:56 p.m. UTC | #4
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
NeilBrown May 5, 2016, 12:09 a.m. UTC | #5
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
Jeffrey Layton May 5, 2016, 7:48 p.m. UTC | #6
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.
David Howells May 5, 2016, 8:04 p.m. UTC | #7
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
Dave Chinner May 6, 2016, 1:39 a.m. UTC | #8
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.
Bruce Fields May 6, 2016, 6:07 p.m. UTC | #9
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
Bruce Fields May 6, 2016, 6:29 p.m. UTC | #10
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
Christoph Hellwig May 8, 2016, 8:35 a.m. UTC | #11
> 	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
Dave Chinner May 9, 2016, 1:45 a.m. UTC | #12
[ 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.
Bruce Fields May 9, 2016, 2:46 a.m. UTC | #13
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
Jeffrey Layton May 9, 2016, 12:02 p.m. UTC | #14
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.
David Howells May 9, 2016, 12:57 p.m. UTC | #15
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 May 9, 2016, 1 p.m. UTC | #16
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
Trond Myklebust May 9, 2016, 1:23 p.m. UTC | #17
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
David Howells May 9, 2016, 1:38 p.m. UTC | #18
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
David Howells May 9, 2016, 1:40 p.m. UTC | #19
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
Christoph Hellwig May 10, 2016, 7 a.m. UTC | #20
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
Christoph Hellwig May 10, 2016, 7:04 a.m. UTC | #21
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
Christoph Hellwig May 10, 2016, 7:08 a.m. UTC | #22
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
David Howells May 10, 2016, 8:25 a.m. UTC | #23
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
David Howells May 10, 2016, 8:43 a.m. UTC | #24
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
Jeffrey Layton May 10, 2016, 1:21 p.m. UTC | #25
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.
Christoph Hellwig May 12, 2016, 9:11 a.m. UTC | #26
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
Christoph Hellwig May 12, 2016, 9:12 a.m. UTC | #27
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
Arnd Bergmann May 13, 2016, 3:28 p.m. UTC | #28
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
David Howells May 18, 2016, 10:55 a.m. UTC | #29
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
Christoph Hellwig May 23, 2016, 8:22 a.m. UTC | #30
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
David Howells May 23, 2016, 9:33 a.m. UTC | #31
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
diff mbox

Patch

========
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;
+}