* [RFC][PATCH 0/6] Enhanced file stat system call
@ 2016-04-29 12:57 David Howells
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
` (7 more replies)
0 siblings, 8 replies; 76+ messages in thread
From: David Howells @ 2016-04-29 12:57 UTC (permalink / raw)
To: linux-fsdevel
Cc: linux-afs, linux-nfs, samba-technical, linux-kernel, dhowells,
linux-ext4
Implement a new system call to provide enhanced file stats. The patches can
be found here:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat
===========
DESCRIPTION
===========
The first patch provides this new system call:
long ret = statx(int dfd,
const char *filename,
unsigned atflag,
unsigned mask,
struct statx *buffer);
This is an enhanced file stat function that provides a number of useful
features, in summary:
(1) More information: creation time, data version number, inode generation
number and flags. A subset of these is available through a number of
filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
(2) Lightweight stat (AT_NO_ATTR_SYNC): Ask for just those details of
interest, and allow a network fs to approximate anything not of
interest, without going to the server.
(3) Heavyweight stat (AT_FORCE_ATTR_SYNC): Force a network fs to flush
buffers and go to the server, even if it thinks its cached attributes
are up to date.
(4) Allow the filesystem to indicate what it can/cannot provide: A
filesystem can now say it doesn't support a standard stat feature if
that isn't available.
(5) Make the fields a consistent size on all arches, and make them large.
(6) Can be extended by using more request flags and using up the padding
space in the statx struct.
Note that no lstat() equivalent is required as that can be implemented
through statx() with atflag == 0. There is also no fstat() equivalent as
that can be implemented through statx() with filename == NULL and the
relevant fd passed as dfd.
=======
TESTING
=======
A test program is added into samples/statx/ by the first patch.
David
---
David Howells (6):
statx: Add a system call to make enhanced file info available
statx: AFS: Return enhanced file attributes
statx: Ext4: Return enhanced file attributes
statx: NFS: Return enhanced file attributes
statx: Make windows attributes available for CIFS, NTFS and FAT to use
statx: CIFS: Return enhanced attributes
arch/x86/entry/syscalls/syscall_32.tbl | 1
arch/x86/entry/syscalls/syscall_64.tbl | 1
fs/afs/inode.c | 24 ++-
fs/cifs/cifsfs.h | 4
fs/cifs/cifsglob.h | 8 +
fs/cifs/dir.c | 2
fs/cifs/inode.c | 117 +++++++++---
fs/exportfs/expfs.c | 4
fs/ext4/ext4.h | 2
fs/ext4/file.c | 2
fs/ext4/inode.c | 30 +++
fs/ext4/namei.c | 2
fs/ext4/symlink.c | 2
fs/nfs/inode.c | 41 ++++
fs/stat.c | 306 +++++++++++++++++++++++++++++---
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 | 135 ++++++++++++++
samples/Makefile | 2
samples/statx/Makefile | 10 +
samples/statx/test-statx.c | 274 +++++++++++++++++++++++++++++
23 files changed, 910 insertions(+), 83 deletions(-)
create mode 100644 samples/statx/Makefile
create mode 100644 samples/statx/test-statx.c
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-04-29 12:57 [RFC][PATCH 0/6] Enhanced file stat system call David Howells
@ 2016-04-29 12:57 ` David Howells
2016-05-02 22:46 ` Andreas Dilger
` (8 more replies)
2016-04-29 12:57 ` [PATCH 2/6] statx: AFS: Return enhanced file attributes David Howells
` (6 subsequent siblings)
7 siblings, 9 replies; 76+ messages in thread
From: David Howells @ 2016-04-29 12:57 UTC (permalink / raw)
To: linux-fsdevel
Cc: linux-afs, linux-nfs, samba-technical, linux-kernel, dhowells,
linux-ext4
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
========
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;
+}
^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 2/6] statx: AFS: Return enhanced file attributes
2016-04-29 12:57 [RFC][PATCH 0/6] Enhanced file stat system call David Howells
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
@ 2016-04-29 12:57 ` David Howells
2016-04-29 12:57 ` [PATCH 3/6] statx: Ext4: " David Howells
` (5 subsequent siblings)
7 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-04-29 12:57 UTC (permalink / raw)
To: linux-fsdevel
Cc: linux-afs, linux-nfs, samba-technical, linux-kernel, dhowells,
linux-ext4
Return enhanced file attributes from the AFS filesystem. This includes the
following:
(1) The data version number as st_version, setting STATX_VERSION.
(2) STATX_INFO_AUTOMOUNT will be set on automount directories by virtue of
S_AUTOMOUNT being set on the inode. These are referrals to other
volumes or other cells.
(3) STATX_INFO_AUTODIR on a directory that does cell lookup for
non-existent names and mounts them (typically mounted on /afs with -o
autocell). The resulting directories are marked STATX_INFO_FABRICATED
as they do not actually exist in the mounted AFS directory.
(4) Files, directories and symlinks accessed over AFS are marked
STATX_INFO_REMOTE. Local fake directories are marked
STATX_INFO_FABRICATED.
(5) STATX_INFO_NONSYSTEM_OWNERSHIP is set as the UID and GID retrieved
from an AFS share may not be applicable on the system.
STATX_ATIME, STATX_CTIME and STATX_BLOCKS are cleared as AFS does not
support them.
Example output:
[root@andromeda ~]# ./samples/statx/test-statx /afs
statx(/afs) = 0
results=7ef
Size: 2048 Blocks: 0 IO Block: 4096 directory
Device: 00:25 Inode: 1 Links: 2
Access: (0777/drwxrwxrwx) Uid: 0 Gid: 0
Access: 2006-05-07 00:21:15.000000000+0100
Modify: 2006-05-07 00:21:15.000000000+0100
Change: 2006-05-07 00:21:15.000000000+0100
IO-blocksize: blksize=4096
Signed-off-by: David Howells <dhowells@redhat.com>
---
fs/afs/inode.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 86cc7264c21c..e9958d5e267e 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -72,9 +72,9 @@ static int afs_inode_map_status(struct afs_vnode *vnode, struct key *key)
inode->i_uid = vnode->status.owner;
inode->i_gid = GLOBAL_ROOT_GID;
inode->i_size = vnode->status.size;
- inode->i_ctime.tv_sec = vnode->status.mtime_server;
- inode->i_ctime.tv_nsec = 0;
- inode->i_atime = inode->i_mtime = inode->i_ctime;
+ inode->i_mtime.tv_sec = vnode->status.mtime_server;
+ inode->i_mtime.tv_nsec = 0;
+ inode->i_atime = inode->i_ctime = inode->i_mtime;
inode->i_blocks = 0;
inode->i_generation = vnode->fid.unique;
inode->i_version = vnode->status.data_version;
@@ -375,8 +375,7 @@ error_unlock:
/*
* read the attributes of an inode
*/
-int afs_getattr(struct vfsmount *mnt, struct dentry *dentry,
- struct kstat *stat)
+int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
{
struct inode *inode;
@@ -385,6 +384,21 @@ int afs_getattr(struct vfsmount *mnt, struct dentry *dentry,
_enter("{ ino=%lu v=%u }", inode->i_ino, inode->i_generation);
generic_fillattr(inode, stat);
+
+ stat->result_mask &= ~(STATX_ATIME | STATX_CTIME | STATX_BLOCKS);
+ stat->result_mask |= STATX_VERSION | STATX_GEN;
+ stat->version = inode->i_version;
+ stat->gen = inode->i_generation;
+
+ if (test_bit(AFS_VNODE_AUTOCELL, &AFS_FS_I(inode)->flags))
+ stat->information |= STATX_INFO_AUTODIR;
+
+ if (test_bit(AFS_VNODE_PSEUDODIR, &AFS_FS_I(inode)->flags))
+ stat->information |= STATX_INFO_FABRICATED;
+ else
+ stat->information |= STATX_INFO_REMOTE;
+
+ stat->information |= STATX_INFO_NONSYSTEM_OWNERSHIP;
return 0;
}
^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 3/6] statx: Ext4: Return enhanced file attributes
2016-04-29 12:57 [RFC][PATCH 0/6] Enhanced file stat system call David Howells
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
2016-04-29 12:57 ` [PATCH 2/6] statx: AFS: Return enhanced file attributes David Howells
@ 2016-04-29 12:57 ` David Howells
2016-05-02 22:48 ` Andreas Dilger
` (2 more replies)
2016-04-29 12:58 ` [PATCH 4/6] statx: NFS: " David Howells
` (4 subsequent siblings)
7 siblings, 3 replies; 76+ messages in thread
From: David Howells @ 2016-04-29 12:57 UTC (permalink / raw)
To: linux-fsdevel
Cc: linux-afs, linux-nfs, samba-technical, linux-kernel, dhowells,
linux-ext4
Return enhanced file attributes from the Ext4 filesystem. This includes
the following:
(1) The inode creation time (i_crtime) as i_btime, setting STATX_BTIME.
(2) The inode i_version as st_version if a file with I_VERSION set or a
directory, setting STATX_VERSION.
(3) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS), setting
STATX_IOC_FLAGS.
This requires that all ext4 inodes have a getattr call, not just some of
them, so to this end, split the ext4_getattr() function and only call part
of it where appropriate.
Example output:
[root@andromeda ~]# ./samples/statx/test-statx /usr
statx(/usr) = 0
results=37ef
Size: 4096 Blocks: 16 IO Block: 4096 directory
Device: 08:02 Inode: 1572865 Links: 14
Access: (0755/drwxr-xr-x) Uid: 0 Gid: 0
Access: 2015-11-03 16:12:30.000000000+0000
Modify: 2013-10-18 15:29:18.000000000+0100
Change: 2013-10-18 15:29:18.000000000+0100
Data version: 2fh
Inode flags: 00000000 (-------- -------- -------- --------)
IO-blocksize: blksize=4096
Signed-off-by: David Howells <dhowells@redhat.com>
---
fs/ext4/ext4.h | 2 ++
fs/ext4/file.c | 2 +-
fs/ext4/inode.c | 30 +++++++++++++++++++++++++++---
fs/ext4/namei.c | 2 ++
fs/ext4/symlink.c | 2 ++
5 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 349afebe21ee..2f25eaa63f39 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2549,6 +2549,8 @@ extern int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct kstat *stat);
extern void ext4_evict_inode(struct inode *);
extern void ext4_clear_inode(struct inode *);
+extern int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
+ struct kstat *stat);
extern int ext4_sync_inode(handle_t *, struct inode *);
extern void ext4_dirty_inode(struct inode *, int);
extern int ext4_change_inode_journal_flag(struct inode *, int);
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index fa2208bae2e1..45c7b8644d0e 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -715,7 +715,7 @@ const struct file_operations ext4_file_operations = {
const struct inode_operations ext4_file_inode_operations = {
.setattr = ext4_setattr,
- .getattr = ext4_getattr,
+ .getattr = ext4_file_getattr,
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,
.listxattr = ext4_listxattr,
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 981a1fc30eaa..309b6cff8afc 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5100,11 +5100,35 @@ err_out:
int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct kstat *stat)
{
- struct inode *inode;
- unsigned long long delalloc_blocks;
+ struct inode *inode = d_inode(dentry);
+ struct ext4_inode *raw_inode;
+ struct ext4_inode_info *ei = EXT4_I(inode);
+
+ stat->result_mask |= STATX_GEN;
+ stat->gen = inode->i_generation;
+
+ if (EXT4_FITS_IN_INODE(raw_inode, ei, i_crtime)) {
+ stat->result_mask |= STATX_BTIME;
+ stat->btime.tv_sec = ei->i_crtime.tv_sec;
+ stat->btime.tv_nsec = ei->i_crtime.tv_nsec;
+ }
+
+ if (S_ISDIR(inode->i_mode) || IS_I_VERSION(inode)) {
+ stat->result_mask |= STATX_VERSION;
+ stat->version = inode->i_version;
+ }
- inode = d_inode(dentry);
generic_fillattr(inode, stat);
+ return 0;
+}
+
+int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
+ struct kstat *stat)
+{
+ struct inode *inode = dentry->d_inode;
+ u64 delalloc_blocks;
+
+ ext4_getattr(mnt, dentry, stat);
/*
* If there is inline data in the inode, the inode will normally not
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 48e4b8907826..9b5fdc971e22 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -3882,6 +3882,7 @@ const struct inode_operations ext4_dir_inode_operations = {
.tmpfile = ext4_tmpfile,
.rename2 = ext4_rename2,
.setattr = ext4_setattr,
+ .getattr = ext4_getattr,
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,
.listxattr = ext4_listxattr,
@@ -3893,6 +3894,7 @@ const struct inode_operations ext4_dir_inode_operations = {
const struct inode_operations ext4_special_inode_operations = {
.setattr = ext4_setattr,
+ .getattr = ext4_getattr,
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,
.listxattr = ext4_listxattr,
diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c
index 75ed5c2f0c16..54015f3d7516 100644
--- a/fs/ext4/symlink.c
+++ b/fs/ext4/symlink.c
@@ -105,6 +105,7 @@ const struct inode_operations ext4_symlink_inode_operations = {
.readlink = generic_readlink,
.get_link = page_get_link,
.setattr = ext4_setattr,
+ .getattr = ext4_getattr,
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,
.listxattr = ext4_listxattr,
@@ -115,6 +116,7 @@ const struct inode_operations ext4_fast_symlink_inode_operations = {
.readlink = generic_readlink,
.get_link = simple_get_link,
.setattr = ext4_setattr,
+ .getattr = ext4_getattr,
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,
.listxattr = ext4_listxattr,
^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 4/6] statx: NFS: Return enhanced file attributes
2016-04-29 12:57 [RFC][PATCH 0/6] Enhanced file stat system call David Howells
` (2 preceding siblings ...)
2016-04-29 12:57 ` [PATCH 3/6] statx: Ext4: " David Howells
@ 2016-04-29 12:58 ` David Howells
2016-05-02 22:48 ` Andreas Dilger
2016-04-29 12:58 ` [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use David Howells
` (3 subsequent siblings)
7 siblings, 1 reply; 76+ messages in thread
From: David Howells @ 2016-04-29 12:58 UTC (permalink / raw)
To: linux-fsdevel
Cc: linux-afs, linux-nfs, samba-technical, linux-kernel, dhowells,
linux-ext4
Return enhanced file atrributes from the NFS filesystem. This includes the
following:
(1) The change attribute as st_version if NFSv4.
(2) STATX_INFO_AUTOMOUNT and STATX_INFO_FABRICATED are set on referral or
submount directories that are automounted upon. NFS shows one
directory with a different FSID, but the local filesystem has two: the
mountpoint directory and the root of the filesystem mounted upon it.
(3) STATX_INFO_REMOTE is set on files acquired over NFS.
(4) STATX_IOC_FLAGS is set and if the atime is unavailable on a file,
st_ioc_flags will have FL_NOATIME_FL set in it.
Furthermore, what nfs_getattr() does can be controlled as follows:
(1) If AT_NO_ATTR_SYNC is indicated then this will suppress the flushing
of outstanding writes and the rereading of the inode's attributes with
the server as detailed below.
(2) Otherwise:
(a) If AT_FORCE_ATTR_SYNC is indicated, or mtime, ctime or
data_version (NFSv4 only) are requested then the outstanding
writes will be written to the server first.
(b) The inode's attributes will be reread from the server:
(i) if AT_FORCE_ATTR_SYNC is indicated;
(ii) if atime is requested (and atime updating is not suppressed by
a mount flag); or
(iii) if the cached attributes have expired;
If the inode isn't synchronised, then the cached attributes will be used -
even if expired - without reference to the server.
Example output:
[root@andromeda ~]# ./samples/statx/test-statx /warthog/
statx(/warthog/) = 0
results=37ef
Size: 4096 Blocks: 8 IO Block: 1048576 directory
Device: 00:26 Inode: 2 Links: 122
Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041
Access: 2015-10-30 16:15:41.730925545+0000
Modify: 2015-10-07 10:33:19.896108112+0100
Change: 2015-10-07 10:33:19.896108112+0100
Data version: 5614e6df35698650h
Inode flags: 00000000 (-------- -------- -------- --------)
Information: 00000010 (-------- -------- -------- ---r----)
IO-blocksize: blksize=1048576
Note that the NFS4 protocol potentially provides a creation time that could
be passed through this interface and system, hidden and archive values that
could be passed as IOC flags. There is also a backup time that could be
added.
Signed-off-by: David Howells <dhowells@redhat.com>
---
fs/nfs/inode.c | 41 ++++++++++++++++++++++++++++++++++-------
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 738c84a42eb0..8637236bca0c 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -655,12 +655,23 @@ static bool nfs_need_revalidate_inode(struct inode *inode)
int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
{
struct inode *inode = d_inode(dentry);
- int need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME;
+ bool force_sync = stat->query_flags & AT_FORCE_ATTR_SYNC;
+ bool suppress_sync = stat->query_flags & AT_NO_ATTR_SYNC;
+ bool need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME;
int err = 0;
trace_nfs_getattr_enter(inode);
- /* Flush out writes to the server in order to update c/mtime. */
- if (S_ISREG(inode->i_mode)) {
+
+ if (NFS_SERVER(inode)->nfs_client->rpc_ops->version < 4)
+ stat->request_mask &= ~STATX_VERSION;
+
+ /* Flush out writes to the server in order to update c/mtime or data
+ * version if the user wants them.
+ */
+ if (S_ISREG(inode->i_mode) && !suppress_sync &&
+ (force_sync || (stat->request_mask &
+ (STATX_MTIME | STATX_CTIME | STATX_VERSION)))
+ ) {
inode_lock(inode);
err = nfs_sync_inode(inode);
inode_unlock(inode);
@@ -677,11 +688,13 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
* - NFS never sets MS_NOATIME or MS_NODIRATIME so there is
* no point in checking those.
*/
- if ((mnt->mnt_flags & MNT_NOATIME) ||
- ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode)))
- need_atime = 0;
+ if (!(stat->request_mask & STATX_ATIME) ||
+ (mnt->mnt_flags & MNT_NOATIME) ||
+ ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode)))
+ need_atime = false;
- if (need_atime || nfs_need_revalidate_inode(inode)) {
+ if (!suppress_sync &&
+ (force_sync || need_atime || nfs_need_revalidate_inode(inode))) {
struct nfs_server *server = NFS_SERVER(inode);
if (server->caps & NFS_CAP_READDIRPLUS)
@@ -694,6 +707,20 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
if (S_ISDIR(inode->i_mode))
stat->blksize = NFS_SERVER(inode)->dtsize;
}
+
+ generic_fillattr(inode, stat);
+ stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode));
+
+ if (stat->request_mask & STATX_VERSION) {
+ stat->version = inode->i_version;
+ stat->result_mask |= STATX_VERSION;
+ }
+
+ if (IS_AUTOMOUNT(inode))
+ stat->information |= STATX_INFO_FABRICATED;
+
+ stat->information |= STATX_INFO_REMOTE;
+
out:
trace_nfs_getattr_exit(inode, err);
return err;
^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use
2016-04-29 12:57 [RFC][PATCH 0/6] Enhanced file stat system call David Howells
` (3 preceding siblings ...)
2016-04-29 12:58 ` [PATCH 4/6] statx: NFS: " David Howells
@ 2016-04-29 12:58 ` David Howells
2016-05-02 22:52 ` Andreas Dilger
` (2 more replies)
2016-04-29 12:58 ` [PATCH 6/6] statx: CIFS: Return enhanced attributes David Howells
` (2 subsequent siblings)
7 siblings, 3 replies; 76+ messages in thread
From: David Howells @ 2016-04-29 12:58 UTC (permalink / raw)
To: linux-fsdevel
Cc: linux-afs, linux-nfs, samba-technical, linux-kernel, dhowells,
linux-ext4
Make windows attributes available for CIFS, NTFS and FAT to use in the
statx struct. The attribute flags map directly by value to those in the
CIFS PDU flags. Some of these bits can also be used by JFS, UFS and HPFS.
The statx struct acquires:
__u32 st_win_attrs;
The value in this is present if STATX_WIN_ATTRS is set.
The defined flags in this are:
STATX_WIN_ATTR_READONLY
STATX_WIN_ATTR_HIDDEN
STATX_WIN_ATTR_SYSTEM
STATX_WIN_ATTR_DIRECTORY
STATX_WIN_ATTR_ARCHIVE
STATX_WIN_ATTR_NORMAL
STATX_WIN_ATTR_TEMPORARY
STATX_WIN_ATTR_SPARSE_FILE
STATX_WIN_ATTR_REPARSE_POINT
STATX_WIN_ATTR_COMPRESSED
STATX_WIN_ATTR_OFFLINE
STATX_WIN_ATTR_NOT_CONTENT_INDEXED
STATX_WIN_ATTR_ENCRYPTED
STATX_WIN_ATTR_INTEGRITY_STREAM
STATX_WIN_ATTR_NO_SCRUB_DATA
Signed-off-by: David Howells <dhowells@redhat.com>
---
fs/stat.c | 5 ++++-
include/uapi/linux/stat.h | 30 ++++++++++++++++++++++++++++--
samples/statx/test-statx.c | 31 +++++++++++++++++++++++++++++++
3 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/fs/stat.c b/fs/stat.c
index c2f8370dab13..1552bff154e6 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -83,6 +83,7 @@ int vfs_xgetattr_nosec(struct path *path, struct kstat *stat)
stat->result_mask = 0;
stat->information = 0;
+ stat->win_attrs = 0;
if (inode->i_op->getattr)
return inode->i_op->getattr(path->mnt, path->dentry, stat);
@@ -643,7 +644,9 @@ static long statx_set_result(struct kstat *stat, struct statx __user *buffer)
__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)))
+ __put_user(stat->win_attrs, &buffer->st_win_attrs ) ||
+ __clear_user(&buffer->__spare1,
+ sizeof(buffer->__spare1) + sizeof(buffer->__spare2)))
return -EFAULT;
return 0;
diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
index 55ce6607dab6..64729b0785bf 100644
--- a/include/uapi/linux/stat.h
+++ b/include/uapi/linux/stat.h
@@ -106,7 +106,10 @@ struct statx {
__u32 st_dev_major; /* ID of device containing file [uncond] */
__u32 st_dev_minor;
/* 0x80 */
- __u64 __spare1[16]; /* Spare space for future expansion */
+ __u32 st_win_attrs; /* Windows file attributes */
+ __u32 __spare1[3];
+ /* 0x90 */
+ __u64 __spare2[14]; /* Spare space for future expansion */
/* 0x100 */
};
@@ -133,7 +136,8 @@ struct statx {
#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 */
+#define STATX_WIN_ATTRS 0x00004000U /* Want/got st_win_attrs */
+#define STATX_ALL_STATS 0x00007fffU /* All supported stats */
/*
* Flags to be found in st_information
@@ -151,4 +155,26 @@ struct statx {
#define STATX_INFO_AUTODIR 0x00000040U /* Dir provides unlisted automounts */
#define STATX_INFO_NONSYSTEM_OWNERSHIP 0x00000080U /* File has non-system ownership details */
+/*
+ * Flags to be found in st_win_attrs.
+ *
+ * These give information about the state of a file on a Windows filesystem
+ * (such as. FAT, NTFS, CIFS). These values are borrowed from the CIFS fs.
+ */
+#define STATX_WIN_ATTR_READONLY 0x00000001
+#define STATX_WIN_ATTR_HIDDEN 0x00000002
+#define STATX_WIN_ATTR_SYSTEM 0x00000004
+#define STATX_WIN_ATTR_DIRECTORY 0x00000010
+#define STATX_WIN_ATTR_ARCHIVE 0x00000020
+#define STATX_WIN_ATTR_NORMAL 0x00000080
+#define STATX_WIN_ATTR_TEMPORARY 0x00000100
+#define STATX_WIN_ATTR_SPARSE_FILE 0x00000200
+#define STATX_WIN_ATTR_REPARSE_POINT 0x00000400
+#define STATX_WIN_ATTR_COMPRESSED 0x00000800
+#define STATX_WIN_ATTR_OFFLINE 0x00001000
+#define STATX_WIN_ATTR_NOT_CONTENT_INDEXED 0x00002000
+#define STATX_WIN_ATTR_ENCRYPTED 0x00004000
+#define STATX_WIN_ATTR_INTEGRITY_STREAM 0x00008000
+#define STATX_WIN_ATTR_NO_SCRUB_DATA 0x00020000
+
#endif /* _UAPI_LINUX_STAT_H */
diff --git a/samples/statx/test-statx.c b/samples/statx/test-statx.c
index 38ef23c12e7d..86eac7d16c32 100644
--- a/samples/statx/test-statx.c
+++ b/samples/statx/test-statx.c
@@ -134,6 +134,37 @@ static void dump_statx(struct statx *stx)
if (stx->st_mask & STATX_GEN)
printf("Inode gen : %xh\n", stx->st_gen);
+ if (stx->st_mask & STATX_WIN_ATTRS) {
+ unsigned char bits;
+ int loop, byte;
+
+ static char wattr_representation[32 + 1] =
+ /* STATX_WIN_ATTR_ flags: */
+ "????????" /* 31-24 0x00000000-ff000000 */
+ "??????N?" /* 23-16 0x00000000-00ff0000 */
+ "ieNocrst" /* 15- 8 0x00000000-0000ff00 */
+ "n?Ad?SHR" /* 7- 0 0x00000000-000000ff */
+ ;
+
+ printf("Win attrs : %08llx (",
+ (unsigned long long)stx->st_win_attrs);
+ for (byte = 32 - 8; byte >= 0; byte -= 8) {
+ bits = stx->st_win_attrs >> byte;
+ for (loop = 7; loop >= 0; loop--) {
+ int bit = byte + loop;
+
+ if (bits & 0x80)
+ putchar(wattr_representation[31 - bit]);
+ else
+ putchar('-');
+ bits <<= 1;
+ }
+ if (byte)
+ putchar(' ');
+ }
+ printf(")\n");
+ }
+
if (stx->st_information) {
unsigned char bits;
int loop, byte;
^ permalink raw reply related [flat|nested] 76+ messages in thread
* [PATCH 6/6] statx: CIFS: Return enhanced attributes
2016-04-29 12:57 [RFC][PATCH 0/6] Enhanced file stat system call David Howells
` (4 preceding siblings ...)
2016-04-29 12:58 ` [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use David Howells
@ 2016-04-29 12:58 ` David Howells
2016-04-30 21:05 ` Jeff Layton
2016-05-04 13:46 ` Arnd Bergmann
7 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-04-29 12:58 UTC (permalink / raw)
To: linux-fsdevel
Cc: linux-afs, linux-nfs, samba-technical, linux-kernel, dhowells,
linux-ext4
Return enhanced attributes from the CIFS filesystem. This includes the
following:
(1) Return the file creation time as btime. We assume that the creation
time won't change over the life of the inode.
(2) Set STATX_INFO_AUTOMOUNT on referral/submount directories.
(3) Unset STATX_INO if we made up the inode number and didn't get it from
the server.
(4) Unset STATX_[UG]ID if we are either returning values passed to mount
and/or the server doesn't return them.
(5) Set STATX_WIN_ATTRS and return windows attributes in st_win_attrs.
(6) Set certain STATX_INFO_xxx to reflect a number of Windows file
attributes:
ATTR_TEMPORARY -> STATX_INFO_TEMPORARY;
ATTR_ENCRYPTED -> STATX_INFO_ENCRYPTED;
(7) Set STATX_INFO_REMOTE on all files fetched by CIFS.
(8) Set STATX_INFO_NONSYSTEM_OWNERSHIP on all files as they all have
Windows ownership details too.
Furthermore, what cifs_getattr() does can be controlled as follows:
(1) If AT_NO_ATTR_SYNC is indicated then this will suppress the flushing
of outstanding writes and the rereading of the inode's attributes with
the server as detailed below.
(2) Otherwise:
(a) If AT_FORCE_ATTR_SYNC is indicated, or mtime, ctime or size are
requested then the outstanding writes will be written to the
server first.
(b) The inode's attributes will be reread from the server:
(i) if AT_FORCE_ATTR_SYNC is indicated;
(ii) if the cached attributes have expired;
(iii) extra attributes are requested that aren't normally stored.
If the inode isn't synchronised, then the cached attributes will be used -
even if expired - without reference to the server. Some attributes may be
unavailable that would otherwise be provided.
Note that cifs_revalidate_dentry() will issue an extra operation to get the
FILE_ALL_INFO in addition to the FILE_UNIX_BASIC_INFO if it needs to
collect creation time and attributes on behalf of cifs_getattr().
[NOTE: THIS PATCH IS UNTESTED!]
Signed-off-by: David Howells <dhowells@redhat.com>
---
fs/cifs/cifsfs.h | 4 +-
fs/cifs/cifsglob.h | 8 ++++
fs/cifs/dir.c | 2 -
fs/cifs/inode.c | 117 ++++++++++++++++++++++++++++++++++++++++------------
4 files changed, 101 insertions(+), 30 deletions(-)
diff --git a/fs/cifs/cifsfs.h b/fs/cifs/cifsfs.h
index 83aac8ba50b0..304f4567d207 100644
--- a/fs/cifs/cifsfs.h
+++ b/fs/cifs/cifsfs.h
@@ -67,9 +67,9 @@ extern int cifs_rmdir(struct inode *, struct dentry *);
extern int cifs_rename2(struct inode *, struct dentry *, struct inode *,
struct dentry *, unsigned int);
extern int cifs_revalidate_file_attr(struct file *filp);
-extern int cifs_revalidate_dentry_attr(struct dentry *);
+extern int cifs_revalidate_dentry_attr(struct dentry *, bool, bool);
extern int cifs_revalidate_file(struct file *filp);
-extern int cifs_revalidate_dentry(struct dentry *);
+extern int cifs_revalidate_dentry(struct dentry *, bool, bool);
extern int cifs_invalidate_mapping(struct inode *inode);
extern int cifs_revalidate_mapping(struct inode *inode);
extern int cifs_zap_mapping(struct inode *inode);
diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index f2cc0b3d1af7..3225b16f7522 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -1166,7 +1166,11 @@ struct cifsInodeInfo {
unsigned long flags;
spinlock_t writers_lock;
unsigned int writers; /* Number of writers on this inode */
+ bool btime_valid:1; /* stored creation time is valid */
+ bool uid_faked:1; /* true if i_uid is faked */
+ bool gid_faked:1; /* true if i_gid is faked */
unsigned long time; /* jiffies of last update of inode */
+ struct timespec btime; /* creation time */
u64 server_eof; /* current file size on server -- protected by i_lock */
u64 uniqueid; /* server inode number */
u64 createtime; /* creation time on server */
@@ -1379,6 +1383,9 @@ struct dfs_info3_param {
#define CIFS_FATTR_NEED_REVAL 0x4
#define CIFS_FATTR_INO_COLLISION 0x8
#define CIFS_FATTR_UNKNOWN_NLINK 0x10
+#define CIFS_FATTR_WINATTRS_VALID 0x20 /* T if cf_btime and cf_cifsattrs valid */
+#define CIFS_FATTR_UID_FAKED 0x40 /* T if cf_uid is faked */
+#define CIFS_FATTR_GID_FAKED 0x80 /* T if cf_gid is faked */
struct cifs_fattr {
u32 cf_flags;
@@ -1396,6 +1403,7 @@ struct cifs_fattr {
struct timespec cf_atime;
struct timespec cf_mtime;
struct timespec cf_ctime;
+ struct timespec cf_btime;
};
static inline void free_dfs_info_param(struct dfs_info3_param *param)
diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
index c3eb998a99bd..4984f04b0677 100644
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -792,7 +792,7 @@ cifs_d_revalidate(struct dentry *direntry, unsigned int flags)
return -ECHILD;
if (d_really_is_positive(direntry)) {
- if (cifs_revalidate_dentry(direntry))
+ if (cifs_revalidate_dentry(direntry, false, false))
return 0;
else {
/*
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 5f9ad5c42180..dc1814b70c81 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -166,13 +166,21 @@ cifs_fattr_to_inode(struct inode *inode, struct cifs_fattr *fattr)
cifs_nlink_fattr_to_inode(inode, fattr);
inode->i_uid = fattr->cf_uid;
inode->i_gid = fattr->cf_gid;
+ if (fattr->cf_flags & CIFS_FATTR_UID_FAKED)
+ cifs_i->uid_faked = true;
+ if (fattr->cf_flags & CIFS_FATTR_GID_FAKED)
+ cifs_i->gid_faked = true;
/* if dynperm is set, don't clobber existing mode */
if (inode->i_state & I_NEW ||
!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_DYNPERM))
inode->i_mode = fattr->cf_mode;
- cifs_i->cifsAttrs = fattr->cf_cifsattrs;
+ if (fattr->cf_flags & CIFS_FATTR_WINATTRS_VALID) {
+ cifs_i->cifsAttrs = fattr->cf_cifsattrs;
+ cifs_i->btime = fattr->cf_btime;
+ cifs_i->btime_valid = true;
+ }
if (fattr->cf_flags & CIFS_FATTR_NEED_REVAL)
cifs_i->time = 0;
@@ -284,18 +292,22 @@ cifs_unix_basic_to_fattr(struct cifs_fattr *fattr, FILE_UNIX_BASIC_INFO *info,
u64 id = le64_to_cpu(info->Uid);
if (id < ((uid_t)-1)) {
kuid_t uid = make_kuid(&init_user_ns, id);
- if (uid_valid(uid))
+ if (uid_valid(uid)) {
fattr->cf_uid = uid;
+ fattr->cf_flags |= CIFS_FATTR_UID_FAKED;
+ }
}
}
-
+
fattr->cf_gid = cifs_sb->mnt_gid;
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID)) {
u64 id = le64_to_cpu(info->Gid);
if (id < ((gid_t)-1)) {
kgid_t gid = make_kgid(&init_user_ns, id);
- if (gid_valid(gid))
+ if (gid_valid(gid)) {
fattr->cf_gid = gid;
+ fattr->cf_flags |= CIFS_FATTR_GID_FAKED;
+ }
}
}
@@ -324,7 +336,8 @@ cifs_create_dfs_fattr(struct cifs_fattr *fattr, struct super_block *sb)
fattr->cf_ctime = CURRENT_TIME;
fattr->cf_mtime = CURRENT_TIME;
fattr->cf_nlink = 2;
- fattr->cf_flags |= CIFS_FATTR_DFS_REFERRAL;
+ fattr->cf_flags |= CIFS_FATTR_DFS_REFERRAL |
+ CIFS_FATTR_UID_FAKED | CIFS_FATTR_GID_FAKED;
}
static int
@@ -590,6 +603,7 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info,
struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb);
memset(fattr, 0, sizeof(*fattr));
+ fattr->cf_flags = CIFS_FATTR_WINATTRS_VALID;
fattr->cf_cifsattrs = le32_to_cpu(info->Attributes);
if (info->DeletePending)
fattr->cf_flags |= CIFS_FATTR_DELETE_PENDING;
@@ -601,6 +615,7 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info,
fattr->cf_ctime = cifs_NTtimeToUnix(info->ChangeTime);
fattr->cf_mtime = cifs_NTtimeToUnix(info->LastWriteTime);
+ fattr->cf_btime = cifs_NTtimeToUnix(info->CreationTime);
if (adjust_tz) {
fattr->cf_ctime.tv_sec += tcon->ses->server->timeAdj;
@@ -1907,7 +1922,8 @@ int cifs_revalidate_file_attr(struct file *filp)
return rc;
}
-int cifs_revalidate_dentry_attr(struct dentry *dentry)
+int cifs_revalidate_dentry_attr(struct dentry *dentry,
+ bool want_extra_bits, bool force)
{
unsigned int xid;
int rc = 0;
@@ -1918,7 +1934,7 @@ int cifs_revalidate_dentry_attr(struct dentry *dentry)
if (inode == NULL)
return -ENOENT;
- if (!cifs_inode_needs_reval(inode))
+ if (!force && !cifs_inode_needs_reval(inode))
return rc;
xid = get_xid();
@@ -1935,9 +1951,12 @@ int cifs_revalidate_dentry_attr(struct dentry *dentry)
full_path, inode, inode->i_count.counter,
dentry, dentry->d_time, jiffies);
- if (cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext)
+ if (cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext) {
rc = cifs_get_inode_info_unix(&inode, full_path, sb, xid);
- else
+ if (rc != 0)
+ goto out;
+ }
+ if (!cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext || want_extra_bits)
rc = cifs_get_inode_info(&inode, full_path, NULL, sb,
xid, NULL);
@@ -1960,12 +1979,13 @@ int cifs_revalidate_file(struct file *filp)
}
/* revalidate a dentry's inode attributes */
-int cifs_revalidate_dentry(struct dentry *dentry)
+int cifs_revalidate_dentry(struct dentry *dentry,
+ bool want_extra_bits, bool force)
{
int rc;
struct inode *inode = d_inode(dentry);
- rc = cifs_revalidate_dentry_attr(dentry);
+ rc = cifs_revalidate_dentry_attr(dentry, want_extra_bits, force);
if (rc)
return rc;
@@ -1978,28 +1998,62 @@ int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct cifs_sb_info *cifs_sb = CIFS_SB(dentry->d_sb);
struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb);
struct inode *inode = d_inode(dentry);
+ struct cifsInodeInfo *cifs_i = CIFS_I(inode);
+ bool force = stat->query_flags & AT_FORCE_ATTR_SYNC;
+ bool want_extra_bits = false;
+ u32 info;
+ u32 attrs;
int rc;
- /*
- * We need to be sure that all dirty pages are written and the server
- * has actual ctime, mtime and file length.
- */
- if (!CIFS_CACHE_READ(CIFS_I(inode)) && inode->i_mapping &&
- inode->i_mapping->nrpages != 0) {
- rc = filemap_fdatawait(inode->i_mapping);
- if (rc) {
- mapping_set_error(inode->i_mapping, rc);
- return rc;
+ if (cifs_i->uid_faked)
+ stat->request_mask &= ~STATX_UID;
+ if (cifs_i->gid_faked)
+ stat->request_mask &= ~STATX_GID;
+
+ if ((stat->request_mask & STATX_BTIME && !cifs_i->btime_valid) ||
+ stat->request_mask & STATX_WIN_ATTRS)
+ want_extra_bits = force = true;
+
+ if (!(stat->query_flags & AT_NO_ATTR_SYNC)) {
+ /* Unless we're explicitly told not to sync, we need to be sure
+ * that all dirty pages are written and the server has actual
+ * ctime, mtime and file length.
+ */
+ bool flush = force;
+
+ if (stat->request_mask &
+ (STATX_CTIME | STATX_MTIME | STATX_SIZE))
+ flush = true;
+
+ if (flush &&
+ !CIFS_CACHE_READ(CIFS_I(inode)) && inode->i_mapping &&
+ inode->i_mapping->nrpages != 0) {
+ rc = filemap_fdatawait(inode->i_mapping);
+ if (rc) {
+ mapping_set_error(inode->i_mapping, rc);
+ return rc;
+ }
}
- }
- rc = cifs_revalidate_dentry_attr(dentry);
- if (rc)
- return rc;
+ rc = cifs_revalidate_dentry(dentry, want_extra_bits, force);
+ if (rc)
+ return rc;
+ }
generic_fillattr(inode, stat);
stat->blksize = CIFS_MAX_MSGSIZE;
- stat->ino = CIFS_I(inode)->uniqueid;
+
+ info = STATX_INFO_REMOTE | STATX_INFO_NONSYSTEM_OWNERSHIP;
+
+ if (cifs_i->btime_valid) {
+ stat->btime = cifs_i->btime;
+ stat->result_mask |= STATX_BTIME;
+ }
+
+ /* We don't promise an inode number if we made one up */
+ stat->ino = cifs_i->uniqueid;
+ if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM))
+ stat->result_mask &= ~STATX_INO;
/*
* If on a multiuser mount without unix extensions or cifsacl being
@@ -2013,8 +2067,17 @@ int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry,
stat->uid = current_fsuid();
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID))
stat->gid = current_fsgid();
+ stat->result_mask &= ~(STATX_UID | STATX_GID);
}
- return rc;
+
+ attrs = cifs_i->cifsAttrs;
+ stat->win_attrs = attrs;
+ if (attrs & ATTR_TEMPORARY) info |= STATX_INFO_TEMPORARY;
+ if (attrs & ATTR_ENCRYPTED) info |= STATX_INFO_ENCRYPTED;
+ stat->information |= info;
+ stat->result_mask |= STATX_WIN_ATTRS;
+
+ return 0;
}
static int cifs_truncate_page(struct address_space *mapping, loff_t from)
^ permalink raw reply related [flat|nested] 76+ messages in thread
* Re: [RFC][PATCH 0/6] Enhanced file stat system call
2016-04-29 12:57 [RFC][PATCH 0/6] Enhanced file stat system call David Howells
@ 2016-04-30 21:05 ` Jeff Layton
2016-04-29 12:57 ` [PATCH 2/6] statx: AFS: Return enhanced file attributes David Howells
` (6 subsequent siblings)
7 siblings, 0 replies; 76+ messages in thread
From: Jeff Layton @ 2016-04-30 21:05 UTC (permalink / raw)
To: David Howells, linux-fsdevel
Cc: linux-afs, linux-nfs, samba-technical, linux-kernel, linux-ext4
On Fri, 2016-04-29 at 13:57 +0100, David Howells wrote:
> Implement a new system call to provide enhanced file stats. The patches can
> be found here:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat
>
>
> ===========
> DESCRIPTION
> ===========
>
> The first patch provides this new system call:
>
> long ret = statx(int dfd,
> const char *filename,
> unsigned atflag,
> unsigned mask,
> struct statx *buffer);
>
> This is an enhanced file stat function that provides a number of useful
> features, in summary:
>
> (1) More information: creation time, data version number, inode generation
> number and flags. A subset of these is available through a number of
> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
>
> (2) Lightweight stat (AT_NO_ATTR_SYNC): Ask for just those details of
> interest, and allow a network fs to approximate anything not of
> interest, without going to the server.
>
> (3) Heavyweight stat (AT_FORCE_ATTR_SYNC): Force a network fs to flush
> buffers and go to the server, even if it thinks its cached attributes
> are up to date.
>
> (4) Allow the filesystem to indicate what it can/cannot provide: A
> filesystem can now say it doesn't support a standard stat feature if
> that isn't available.
>
> (5) Make the fields a consistent size on all arches, and make them large.
>
> (6) Can be extended by using more request flags and using up the padding
> space in the statx struct.
>
> Note that no lstat() equivalent is required as that can be implemented
> through statx() with atflag == 0. There is also no fstat() equivalent as
> that can be implemented through statx() with filename == NULL and the
> relevant fd passed as dfd.
>
>
> =======
> TESTING
> =======
>
> A test program is added into samples/statx/ by the first patch.
>
> David
> ---
> David Howells (6):
> statx: Add a system call to make enhanced file info available
> statx: AFS: Return enhanced file attributes
> statx: Ext4: Return enhanced file attributes
> statx: NFS: Return enhanced file attributes
> statx: Make windows attributes available for CIFS, NTFS and FAT to use
> statx: CIFS: Return enhanced attributes
>
>
> arch/x86/entry/syscalls/syscall_32.tbl | 1
> arch/x86/entry/syscalls/syscall_64.tbl | 1
> fs/afs/inode.c | 24 ++-
> fs/cifs/cifsfs.h | 4
> fs/cifs/cifsglob.h | 8 +
> fs/cifs/dir.c | 2
> fs/cifs/inode.c | 117 +++++++++---
> fs/exportfs/expfs.c | 4
> fs/ext4/ext4.h | 2
> fs/ext4/file.c | 2
> fs/ext4/inode.c | 30 +++
> fs/ext4/namei.c | 2
> fs/ext4/symlink.c | 2
> fs/nfs/inode.c | 41 ++++
> fs/stat.c | 306 +++++++++++++++++++++++++++++---
> 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 | 135 ++++++++++++++
> samples/Makefile | 2
> samples/statx/Makefile | 10 +
> samples/statx/test-statx.c | 274 +++++++++++++++++++++++++++++
> 23 files changed, 910 insertions(+), 83 deletions(-)
> create mode 100644 samples/statx/Makefile
> create mode 100644 samples/statx/test-statx.c
>
I looked over the patchset and it looks fairly straightforward to me.
Are there things that I'd have probably done differently? Yes, but
nothing really sticks out to me as show-stopping and this has the
potential to be helpful in all sorts of ways.
I think we really ought to resist excessive bikeshedding this time
around. With the way the interface is designed, we should be able to
expand on it later if we want to add new attributes after the interface
itself is merged.
Reviewed-by: Jeff Layton <jlayton@poochiereds.net>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [RFC][PATCH 0/6] Enhanced file stat system call
@ 2016-04-30 21:05 ` Jeff Layton
0 siblings, 0 replies; 76+ messages in thread
From: Jeff Layton @ 2016-04-30 21:05 UTC (permalink / raw)
To: David Howells, linux-fsdevel
Cc: linux-afs, linux-nfs, samba-technical, linux-kernel, linux-ext4
On Fri, 2016-04-29 at 13:57 +0100, David Howells wrote:
> Implement a new system call to provide enhanced file stats. The patches can
> be found here:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat
>
>
> ===========
> DESCRIPTION
> ===========
>
> The first patch provides this new system call:
>
> long ret = statx(int dfd,
> const char *filename,
> unsigned atflag,
> unsigned mask,
> struct statx *buffer);
>
> This is an enhanced file stat function that provides a number of useful
> features, in summary:
>
> (1) More information: creation time, data version number, inode generation
> number and flags. A subset of these is available through a number of
> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
>
> (2) Lightweight stat (AT_NO_ATTR_SYNC): Ask for just those details of
> interest, and allow a network fs to approximate anything not of
> interest, without going to the server.
>
> (3) Heavyweight stat (AT_FORCE_ATTR_SYNC): Force a network fs to flush
> buffers and go to the server, even if it thinks its cached attributes
> are up to date.
>
> (4) Allow the filesystem to indicate what it can/cannot provide: A
> filesystem can now say it doesn't support a standard stat feature if
> that isn't available.
>
> (5) Make the fields a consistent size on all arches, and make them large.
>
> (6) Can be extended by using more request flags and using up the padding
> space in the statx struct.
>
> Note that no lstat() equivalent is required as that can be implemented
> through statx() with atflag == 0. There is also no fstat() equivalent as
> that can be implemented through statx() with filename == NULL and the
> relevant fd passed as dfd.
>
>
> =======
> TESTING
> =======
>
> A test program is added into samples/statx/ by the first patch.
>
> David
> ---
> David Howells (6):
> statx: Add a system call to make enhanced file info available
> statx: AFS: Return enhanced file attributes
> statx: Ext4: Return enhanced file attributes
> statx: NFS: Return enhanced file attributes
> statx: Make windows attributes available for CIFS, NTFS and FAT to use
> statx: CIFS: Return enhanced attributes
>
>
> arch/x86/entry/syscalls/syscall_32.tbl | 1
> arch/x86/entry/syscalls/syscall_64.tbl | 1
> fs/afs/inode.c | 24 ++-
> fs/cifs/cifsfs.h | 4
> fs/cifs/cifsglob.h | 8 +
> fs/cifs/dir.c | 2
> fs/cifs/inode.c | 117 +++++++++---
> fs/exportfs/expfs.c | 4
> fs/ext4/ext4.h | 2
> fs/ext4/file.c | 2
> fs/ext4/inode.c | 30 +++
> fs/ext4/namei.c | 2
> fs/ext4/symlink.c | 2
> fs/nfs/inode.c | 41 ++++
> fs/stat.c | 306 +++++++++++++++++++++++++++++---
> 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 | 135 ++++++++++++++
> samples/Makefile | 2
> samples/statx/Makefile | 10 +
> samples/statx/test-statx.c | 274 +++++++++++++++++++++++++++++
> 23 files changed, 910 insertions(+), 83 deletions(-)
> create mode 100644 samples/statx/Makefile
> create mode 100644 samples/statx/test-statx.c
>
I looked over the patchset and it looks fairly straightforward to me.
Are there things that I'd have probably done differently? Yes, but
nothing really sticks out to me as show-stopping and this has the
potential to be helpful in all sorts of ways.
I think we really ought to resist excessive bikeshedding this time
around. With the way the interface is designed, we should be able to
expand on it later if we want to add new attributes after the interface
itself is merged.
Reviewed-by: Jeff Layton <jlayton@poochiereds.net>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-02 22:46 ` Andreas Dilger
0 siblings, 0 replies; 76+ messages in thread
From: Andreas Dilger @ 2016-05-02 22:46 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
[-- Attachment #1: Type: text/plain, Size: 46979 bytes --]
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
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-02 22:46 ` Andreas Dilger
0 siblings, 0 replies; 76+ messages in thread
From: Andreas Dilger @ 2016-05-02 22:46 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 47090 bytes --]
On Apr 29, 2016, at 6:57 AM, David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>
> 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org)
> + *
> + * 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers, Andreas
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 3/6] statx: Ext4: Return enhanced file attributes
2016-04-29 12:57 ` [PATCH 3/6] statx: Ext4: " David Howells
@ 2016-05-02 22:48 ` Andreas Dilger
2016-05-03 20:24 ` David Howells
2016-05-08 8:38 ` Christoph Hellwig
2 siblings, 0 replies; 76+ messages in thread
From: Andreas Dilger @ 2016-05-02 22:48 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
[-- Attachment #1: Type: text/plain, Size: 6474 bytes --]
On Apr 29, 2016, at 6:57 AM, David Howells <dhowells@redhat.com> wrote:
>
> Return enhanced file attributes from the Ext4 filesystem. This includes
> the following:
>
> (1) The inode creation time (i_crtime) as i_btime, setting STATX_BTIME.
>
> (2) The inode i_version as st_version if a file with I_VERSION set or a
> directory, setting STATX_VERSION.
>
> (3) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS), setting
> STATX_IOC_FLAGS.
I don't see where this is implemented in this patch, and it should be
removed from the commit message to avoid confusion.
> This requires that all ext4 inodes have a getattr call, not just some of
> them, so to this end, split the ext4_getattr() function and only call part
> of it where appropriate.
>
> Example output:
>
> [root@andromeda ~]# ./samples/statx/test-statx /usr
> statx(/usr) = 0
> results=37ef
> Size: 4096 Blocks: 16 IO Block: 4096 directory
> Device: 08:02 Inode: 1572865 Links: 14
> Access: (0755/drwxr-xr-x) Uid: 0 Gid: 0
> Access: 2015-11-03 16:12:30.000000000+0000
> Modify: 2013-10-18 15:29:18.000000000+0100
> Change: 2013-10-18 15:29:18.000000000+0100
> Data version: 2fh
> Inode flags: 00000000 (-------- -------- -------- --------)
> IO-blocksize: blksize=4096
One minor strangeness in this commit message is that the above usage example
doesn't include nanoseconds or Birth time for ext4, when this should be
supported for all ext4 filesystems? Was this example run on an older ext3
filesystem (or some filesystem upgraded from ext3)? Any ext4-formatted fs
should have the larger inode size to handle these extra fields.
Also a bit strange that "IO Block: 4096" and "IO-blocksize: blksize=4096"
is listed twice, but that seems to be an issue with the test-statx tool
and not necessarily the data being returned.
Cheers, Andreas
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> fs/ext4/ext4.h | 2 ++
> fs/ext4/file.c | 2 +-
> fs/ext4/inode.c | 30 +++++++++++++++++++++++++++---
> fs/ext4/namei.c | 2 ++
> fs/ext4/symlink.c | 2 ++
> 5 files changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 349afebe21ee..2f25eaa63f39 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -2549,6 +2549,8 @@ extern int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
> struct kstat *stat);
> extern void ext4_evict_inode(struct inode *);
> extern void ext4_clear_inode(struct inode *);
> +extern int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
> + struct kstat *stat);
> extern int ext4_sync_inode(handle_t *, struct inode *);
> extern void ext4_dirty_inode(struct inode *, int);
> extern int ext4_change_inode_journal_flag(struct inode *, int);
> diff --git a/fs/ext4/file.c b/fs/ext4/file.c
> index fa2208bae2e1..45c7b8644d0e 100644
> --- a/fs/ext4/file.c
> +++ b/fs/ext4/file.c
> @@ -715,7 +715,7 @@ const struct file_operations ext4_file_operations = {
>
> const struct inode_operations ext4_file_inode_operations = {
> .setattr = ext4_setattr,
> - .getattr = ext4_getattr,
> + .getattr = ext4_file_getattr,
> .setxattr = generic_setxattr,
> .getxattr = generic_getxattr,
> .listxattr = ext4_listxattr,
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 981a1fc30eaa..309b6cff8afc 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -5100,11 +5100,35 @@ err_out:
> int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry,
> struct kstat *stat)
> {
> - struct inode *inode;
> - unsigned long long delalloc_blocks;
> + struct inode *inode = d_inode(dentry);
> + struct ext4_inode *raw_inode;
> + struct ext4_inode_info *ei = EXT4_I(inode);
> +
> + stat->result_mask |= STATX_GEN;
> + stat->gen = inode->i_generation;
> +
> + if (EXT4_FITS_IN_INODE(raw_inode, ei, i_crtime)) {
> + stat->result_mask |= STATX_BTIME;
> + stat->btime.tv_sec = ei->i_crtime.tv_sec;
> + stat->btime.tv_nsec = ei->i_crtime.tv_nsec;
> + }
> +
> + if (S_ISDIR(inode->i_mode) || IS_I_VERSION(inode)) {
> + stat->result_mask |= STATX_VERSION;
> + stat->version = inode->i_version;
> + }
>
> - inode = d_inode(dentry);
> generic_fillattr(inode, stat);
> + return 0;
> +}
> +
> +int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry,
> + struct kstat *stat)
> +{
> + struct inode *inode = dentry->d_inode;
> + u64 delalloc_blocks;
> +
> + ext4_getattr(mnt, dentry, stat);
>
> /*
> * If there is inline data in the inode, the inode will normally not
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index 48e4b8907826..9b5fdc971e22 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -3882,6 +3882,7 @@ const struct inode_operations ext4_dir_inode_operations = {
> .tmpfile = ext4_tmpfile,
> .rename2 = ext4_rename2,
> .setattr = ext4_setattr,
> + .getattr = ext4_getattr,
> .setxattr = generic_setxattr,
> .getxattr = generic_getxattr,
> .listxattr = ext4_listxattr,
> @@ -3893,6 +3894,7 @@ const struct inode_operations ext4_dir_inode_operations = {
>
> const struct inode_operations ext4_special_inode_operations = {
> .setattr = ext4_setattr,
> + .getattr = ext4_getattr,
> .setxattr = generic_setxattr,
> .getxattr = generic_getxattr,
> .listxattr = ext4_listxattr,
> diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c
> index 75ed5c2f0c16..54015f3d7516 100644
> --- a/fs/ext4/symlink.c
> +++ b/fs/ext4/symlink.c
> @@ -105,6 +105,7 @@ const struct inode_operations ext4_symlink_inode_operations = {
> .readlink = generic_readlink,
> .get_link = page_get_link,
> .setattr = ext4_setattr,
> + .getattr = ext4_getattr,
> .setxattr = generic_setxattr,
> .getxattr = generic_getxattr,
> .listxattr = ext4_listxattr,
> @@ -115,6 +116,7 @@ const struct inode_operations ext4_fast_symlink_inode_operations = {
> .readlink = generic_readlink,
> .get_link = simple_get_link,
> .setattr = ext4_setattr,
> + .getattr = ext4_getattr,
> .setxattr = generic_setxattr,
> .getxattr = generic_getxattr,
> .listxattr = ext4_listxattr,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers, Andreas
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 4/6] statx: NFS: Return enhanced file attributes
2016-04-29 12:58 ` [PATCH 4/6] statx: NFS: " David Howells
@ 2016-05-02 22:48 ` Andreas Dilger
0 siblings, 0 replies; 76+ messages in thread
From: Andreas Dilger @ 2016-05-02 22:48 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
[-- Attachment #1: Type: text/plain, Size: 5967 bytes --]
On Apr 29, 2016, at 6:58 AM, David Howells <dhowells@redhat.com> wrote:
>
> Return enhanced file atrributes from the NFS filesystem. This includes the
> following:
>
> (1) The change attribute as st_version if NFSv4.
>
> (2) STATX_INFO_AUTOMOUNT and STATX_INFO_FABRICATED are set on referral or
> submount directories that are automounted upon. NFS shows one
> directory with a different FSID, but the local filesystem has two: the
> mountpoint directory and the root of the filesystem mounted upon it.
>
> (3) STATX_INFO_REMOTE is set on files acquired over NFS.
>
> (4) STATX_IOC_FLAGS is set and if the atime is unavailable on a file,
> st_ioc_flags will have FL_NOATIME_FL set in it.
This is not implemented in this patch, and should removed from the commit
message. The generic_fillattr() change in [1/6] will clear the STATX_ATIME
flag if IS_NOATIME() is true, so maybe that is enough for what you intended?
Cheers, Andreas
> Furthermore, what nfs_getattr() does can be controlled as follows:
>
> (1) If AT_NO_ATTR_SYNC is indicated then this will suppress the flushing
> of outstanding writes and the rereading of the inode's attributes with
> the server as detailed below.
>
> (2) Otherwise:
>
> (a) If AT_FORCE_ATTR_SYNC is indicated, or mtime, ctime or
> data_version (NFSv4 only) are requested then the outstanding
> writes will be written to the server first.
>
> (b) The inode's attributes will be reread from the server:
>
> (i) if AT_FORCE_ATTR_SYNC is indicated;
>
> (ii) if atime is requested (and atime updating is not suppressed by
> a mount flag); or
>
> (iii) if the cached attributes have expired;
>
> If the inode isn't synchronised, then the cached attributes will be used -
> even if expired - without reference to the server.
>
> Example output:
>
> [root@andromeda ~]# ./samples/statx/test-statx /warthog/
> statx(/warthog/) = 0
> results=37ef
> Size: 4096 Blocks: 8 IO Block: 1048576 directory
> Device: 00:26 Inode: 2 Links: 122
> Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041
> Access: 2015-10-30 16:15:41.730925545+0000
> Modify: 2015-10-07 10:33:19.896108112+0100
> Change: 2015-10-07 10:33:19.896108112+0100
> Data version: 5614e6df35698650h
> Inode flags: 00000000 (-------- -------- -------- --------)
> Information: 00000010 (-------- -------- -------- ---r----)
> IO-blocksize: blksize=1048576
>
> Note that the NFS4 protocol potentially provides a creation time that could
> be passed through this interface and system, hidden and archive values that
> could be passed as IOC flags. There is also a backup time that could be
> added.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> fs/nfs/inode.c | 41 ++++++++++++++++++++++++++++++++++-------
> 1 file changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
> index 738c84a42eb0..8637236bca0c 100644
> --- a/fs/nfs/inode.c
> +++ b/fs/nfs/inode.c
> @@ -655,12 +655,23 @@ static bool nfs_need_revalidate_inode(struct inode *inode)
> int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
> {
> struct inode *inode = d_inode(dentry);
> - int need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME;
> + bool force_sync = stat->query_flags & AT_FORCE_ATTR_SYNC;
> + bool suppress_sync = stat->query_flags & AT_NO_ATTR_SYNC;
> + bool need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME;
> int err = 0;
>
> trace_nfs_getattr_enter(inode);
> - /* Flush out writes to the server in order to update c/mtime. */
> - if (S_ISREG(inode->i_mode)) {
> +
> + if (NFS_SERVER(inode)->nfs_client->rpc_ops->version < 4)
> + stat->request_mask &= ~STATX_VERSION;
> +
> + /* Flush out writes to the server in order to update c/mtime or data
> + * version if the user wants them.
> + */
> + if (S_ISREG(inode->i_mode) && !suppress_sync &&
> + (force_sync || (stat->request_mask &
> + (STATX_MTIME | STATX_CTIME | STATX_VERSION)))
> + ) {
> inode_lock(inode);
> err = nfs_sync_inode(inode);
> inode_unlock(inode);
> @@ -677,11 +688,13 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
> * - NFS never sets MS_NOATIME or MS_NODIRATIME so there is
> * no point in checking those.
> */
> - if ((mnt->mnt_flags & MNT_NOATIME) ||
> - ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode)))
> - need_atime = 0;
> + if (!(stat->request_mask & STATX_ATIME) ||
> + (mnt->mnt_flags & MNT_NOATIME) ||
> + ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode)))
> + need_atime = false;
>
> - if (need_atime || nfs_need_revalidate_inode(inode)) {
> + if (!suppress_sync &&
> + (force_sync || need_atime || nfs_need_revalidate_inode(inode))) {
> struct nfs_server *server = NFS_SERVER(inode);
>
> if (server->caps & NFS_CAP_READDIRPLUS)
> @@ -694,6 +707,20 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat)
> if (S_ISDIR(inode->i_mode))
> stat->blksize = NFS_SERVER(inode)->dtsize;
> }
> +
> + generic_fillattr(inode, stat);
> + stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode));
> +
> + if (stat->request_mask & STATX_VERSION) {
> + stat->version = inode->i_version;
> + stat->result_mask |= STATX_VERSION;
> + }
> +
> + if (IS_AUTOMOUNT(inode))
> + stat->information |= STATX_INFO_FABRICATED;
> +
> + stat->information |= STATX_INFO_REMOTE;
> +
> out:
> trace_nfs_getattr_exit(inode, err);
> return err;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers, Andreas
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use
2016-04-29 12:58 ` [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use David Howells
@ 2016-05-02 22:52 ` Andreas Dilger
2016-10-03 21:03 ` Steve French
2016-05-03 20:23 ` David Howells
2016-05-08 8:39 ` Christoph Hellwig
2 siblings, 1 reply; 76+ messages in thread
From: Andreas Dilger @ 2016-05-02 22:52 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
[-- Attachment #1: Type: text/plain, Size: 6855 bytes --]
On Apr 29, 2016, at 6:58 AM, David Howells <dhowells@redhat.com> wrote:
>
> Make windows attributes available for CIFS, NTFS and FAT to use in the
> statx struct. The attribute flags map directly by value to those in the
> CIFS PDU flags. Some of these bits can also be used by JFS, UFS and HPFS.
>
> The statx struct acquires:
>
> __u32 st_win_attrs;
It seems some of these flags are duplicated with the st_information field,
and some are duplicate with FS_IOC_GETFLAGS values, and returning the same
information in multiple ways is confusing.
If these flags are part of the CIFS protocol, and are directly usable by
Samba then I can understand we wouldn't want to change them once in the
kernel and then convert them back in userspace, but I'm a bit reluctant
to have flags only for CIFS/NTFS/FAT that might also be useful for other filesystems. Would we want to be able to get translated st_win_attrs
flags in ext4 attrs when it is being exported by Samba?
> The value in this is present if STATX_WIN_ATTRS is set.
>
> The defined flags in this are:
>
> STATX_WIN_ATTR_READONLY
> STATX_WIN_ATTR_HIDDEN
> STATX_WIN_ATTR_SYSTEM
> STATX_WIN_ATTR_DIRECTORY
How does this differ from (st_mode & S_IFMT) == S_IFDIR)?
> STATX_WIN_ATTR_ARCHIVE
> STATX_WIN_ATTR_NORMAL
How does this differ from (st_mode & S_IFMT) == S_IFREG)?
> STATX_WIN_ATTR_TEMPORARY
How does this differ from STATX_INFO_TEMPORARY?
> STATX_WIN_ATTR_SPARSE_FILE
> STATX_WIN_ATTR_REPARSE_POINT
> STATX_WIN_ATTR_COMPRESSED
> STATX_WIN_ATTR_OFFLINE
> STATX_WIN_ATTR_NOT_CONTENT_INDEXED
> STATX_WIN_ATTR_ENCRYPTED
How does this differ from STATX_INFO_ENCRYPTED?
Cheers, Andreas
> STATX_WIN_ATTR_INTEGRITY_STREAM
> STATX_WIN_ATTR_NO_SCRUB_DATA
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> fs/stat.c | 5 ++++-
> include/uapi/linux/stat.h | 30 ++++++++++++++++++++++++++++--
> samples/statx/test-statx.c | 31 +++++++++++++++++++++++++++++++
> 3 files changed, 63 insertions(+), 3 deletions(-)
>
> diff --git a/fs/stat.c b/fs/stat.c
> index c2f8370dab13..1552bff154e6 100644
> --- a/fs/stat.c
> +++ b/fs/stat.c
> @@ -83,6 +83,7 @@ int vfs_xgetattr_nosec(struct path *path, struct kstat *stat)
>
> stat->result_mask = 0;
> stat->information = 0;
> + stat->win_attrs = 0;
> if (inode->i_op->getattr)
> return inode->i_op->getattr(path->mnt, path->dentry, stat);
>
> @@ -643,7 +644,9 @@ static long statx_set_result(struct kstat *stat, struct statx __user *buffer)
> __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)))
> + __put_user(stat->win_attrs, &buffer->st_win_attrs ) ||
> + __clear_user(&buffer->__spare1,
> + sizeof(buffer->__spare1) + sizeof(buffer->__spare2)))
> return -EFAULT;
>
> return 0;
> diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
> index 55ce6607dab6..64729b0785bf 100644
> --- a/include/uapi/linux/stat.h
> +++ b/include/uapi/linux/stat.h
> @@ -106,7 +106,10 @@ struct statx {
> __u32 st_dev_major; /* ID of device containing file [uncond] */
> __u32 st_dev_minor;
> /* 0x80 */
> - __u64 __spare1[16]; /* Spare space for future expansion */
> + __u32 st_win_attrs; /* Windows file attributes */
> + __u32 __spare1[3];
> + /* 0x90 */
> + __u64 __spare2[14]; /* Spare space for future expansion */
> /* 0x100 */
> };
>
> @@ -133,7 +136,8 @@ struct statx {
> #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 */
> +#define STATX_WIN_ATTRS 0x00004000U /* Want/got st_win_attrs */
> +#define STATX_ALL_STATS 0x00007fffU /* All supported stats */
>
> /*
> * Flags to be found in st_information
> @@ -151,4 +155,26 @@ struct statx {
> #define STATX_INFO_AUTODIR 0x00000040U /* Dir provides unlisted automounts */
> #define STATX_INFO_NONSYSTEM_OWNERSHIP 0x00000080U /* File has non-system ownership details */
>
> +/*
> + * Flags to be found in st_win_attrs.
> + *
> + * These give information about the state of a file on a Windows filesystem
> + * (such as. FAT, NTFS, CIFS). These values are borrowed from the CIFS fs.
> + */
> +#define STATX_WIN_ATTR_READONLY 0x00000001
> +#define STATX_WIN_ATTR_HIDDEN 0x00000002
> +#define STATX_WIN_ATTR_SYSTEM 0x00000004
> +#define STATX_WIN_ATTR_DIRECTORY 0x00000010
> +#define STATX_WIN_ATTR_ARCHIVE 0x00000020
> +#define STATX_WIN_ATTR_NORMAL 0x00000080
> +#define STATX_WIN_ATTR_TEMPORARY 0x00000100
> +#define STATX_WIN_ATTR_SPARSE_FILE 0x00000200
> +#define STATX_WIN_ATTR_REPARSE_POINT 0x00000400
> +#define STATX_WIN_ATTR_COMPRESSED 0x00000800
> +#define STATX_WIN_ATTR_OFFLINE 0x00001000
> +#define STATX_WIN_ATTR_NOT_CONTENT_INDEXED 0x00002000
> +#define STATX_WIN_ATTR_ENCRYPTED 0x00004000
> +#define STATX_WIN_ATTR_INTEGRITY_STREAM 0x00008000
> +#define STATX_WIN_ATTR_NO_SCRUB_DATA 0x00020000
> +
> #endif /* _UAPI_LINUX_STAT_H */
> diff --git a/samples/statx/test-statx.c b/samples/statx/test-statx.c
> index 38ef23c12e7d..86eac7d16c32 100644
> --- a/samples/statx/test-statx.c
> +++ b/samples/statx/test-statx.c
> @@ -134,6 +134,37 @@ static void dump_statx(struct statx *stx)
> if (stx->st_mask & STATX_GEN)
> printf("Inode gen : %xh\n", stx->st_gen);
>
> + if (stx->st_mask & STATX_WIN_ATTRS) {
> + unsigned char bits;
> + int loop, byte;
> +
> + static char wattr_representation[32 + 1] =
> + /* STATX_WIN_ATTR_ flags: */
> + "????????" /* 31-24 0x00000000-ff000000 */
> + "??????N?" /* 23-16 0x00000000-00ff0000 */
> + "ieNocrst" /* 15- 8 0x00000000-0000ff00 */
> + "n?Ad?SHR" /* 7- 0 0x00000000-000000ff */
> + ;
> +
> + printf("Win attrs : %08llx (",
> + (unsigned long long)stx->st_win_attrs);
> + for (byte = 32 - 8; byte >= 0; byte -= 8) {
> + bits = stx->st_win_attrs >> byte;
> + for (loop = 7; loop >= 0; loop--) {
> + int bit = byte + loop;
> +
> + if (bits & 0x80)
> + putchar(wattr_representation[31 - bit]);
> + else
> + putchar('-');
> + bits <<= 1;
> + }
> + if (byte)
> + putchar(' ');
> + }
> + printf(")\n");
> + }
> +
> if (stx->st_information) {
> unsigned char bits;
> int loop, byte;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers, Andreas
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
2016-05-02 22:46 ` Andreas Dilger
@ 2016-05-03 15:53 ` David Howells
2016-05-04 22:56 ` Dave Chinner
` (6 subsequent siblings)
8 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-03 15:53 UTC (permalink / raw)
To: Andreas Dilger
Cc: dhowells, linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use
2016-04-29 12:58 ` [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use David Howells
2016-05-02 22:52 ` Andreas Dilger
@ 2016-05-03 20:23 ` David Howells
2016-05-08 8:39 ` Christoph Hellwig
2 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-03 20:23 UTC (permalink / raw)
To: Andreas Dilger
Cc: dhowells, linux-fsdevel, linux-nfs, samba-technical,
linux-kernel, linux-ext4
Andreas Dilger <adilger@dilger.ca> wrote:
> > __u32 st_win_attrs;
>
> It seems some of these flags are duplicated with the st_information field,
> and some are duplicate with FS_IOC_GETFLAGS values, and returning the same
> information in multiple ways is confusing.
>
> If these flags are part of the CIFS protocol,
They're part of the Windows API. CIFS/SMB and NTFS have them at the same
values.
> and are directly usable by Samba then I can understand we wouldn't want to
> change them once in the kernel and then convert them back in userspace, but
> I'm a bit reluctant to have flags only for CIFS/NTFS/FAT that might also be
> useful for other filesystems.
Where said "other filesystems" have some support for Windows or OS/2 and have
bits defined that map directly in semantics, if not in value, to these bits.
JFS, for example, has IREADONLY, IHIDDEN, ISYSTEM, IDIRECTORY, IARCHIVE and
ISPARSE.
> Would we want to be able to get translated
> st_win_attrs flags in ext4 attrs when it is being exported by Samba?
Actually, I was thinking of proposing an ext4 patch that stored windows flags
in a separate word in the inode on disk. There isn't sufficient bit space to
map all the windows flags to FS_IOC_GETFLAGS. However, as you say, there is a
certain amount of overlap...
David
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 3/6] statx: Ext4: Return enhanced file attributes
@ 2016-05-03 20:24 ` David Howells
0 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-03 20:24 UTC (permalink / raw)
To: Andreas Dilger
Cc: dhowells, linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
Andreas Dilger <adilger@dilger.ca> wrote:
> > (3) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS), setting
> > STATX_IOC_FLAGS.
>
> I don't see where this is implemented in this patch, and it should be
> removed from the commit message to avoid confusion.
Oops - I forgot to remove it from the other patches.
David
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 3/6] statx: Ext4: Return enhanced file attributes
@ 2016-05-03 20:24 ` David Howells
0 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-03 20:24 UTC (permalink / raw)
To: Andreas Dilger
Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA
Andreas Dilger <adilger-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org> wrote:
> > (3) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS), setting
> > STATX_IOC_FLAGS.
>
> I don't see where this is implemented in this patch, and it should be
> removed from the commit message to avoid confusion.
Oops - I forgot to remove it from the other patches.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [RFC][PATCH 0/6] Enhanced file stat system call
@ 2016-05-04 13:46 ` Arnd Bergmann
0 siblings, 0 replies; 76+ messages in thread
From: Arnd Bergmann @ 2016-05-04 13:46 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4, deepa.kernel
On Friday 29 April 2016 13:57:36 David Howells wrote:
> struct statx *buffer);
>
> This is an enhanced file stat function that provides a number of useful
> features, in summary:
>
> (1) More information: creation time, data version number, inode generation
> number and flags. A subset of these is available through a number of
> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
>
I have a question about birthtime/creationtime: As we are gaining a way
to read this, should we also provide a way to update it using a new variant
of the utimensat syscall in order to have 'cp -a' create an identical copy,
or is the idea that this is defined as the time that is particular copy
of the inode was created?
I've discussed this with Deepa in the past, as she is driving the
convertion of the inode timestamps to timespec64 now, and we will
need a new version of utimensat for her work as well. I can see good
reasons either way (allowing updates of btime or disallowing them).
This should not hold up the statx syscall from getting merged as
soon as we can, but I'd like to know what everyone feels about that
question now that they are looking at the interface already.
Arnd
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [RFC][PATCH 0/6] Enhanced file stat system call
@ 2016-05-04 13:46 ` Arnd Bergmann
0 siblings, 0 replies; 76+ messages in thread
From: Arnd Bergmann @ 2016-05-04 13:46 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA,
deepa.kernel-Re5JQEeQqe8AvxtiuMwx3w
On Friday 29 April 2016 13:57:36 David Howells wrote:
> struct statx *buffer);
>
> This is an enhanced file stat function that provides a number of useful
> features, in summary:
>
> (1) More information: creation time, data version number, inode generation
> number and flags. A subset of these is available through a number of
> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
>
I have a question about birthtime/creationtime: As we are gaining a way
to read this, should we also provide a way to update it using a new variant
of the utimensat syscall in order to have 'cp -a' create an identical copy,
or is the idea that this is defined as the time that is particular copy
of the inode was created?
I've discussed this with Deepa in the past, as she is driving the
convertion of the inode timestamps to timespec64 now, and we will
need a new version of utimensat for her work as well. I can see good
reasons either way (allowing updates of btime or disallowing them).
This should not hold up the statx syscall from getting merged as
soon as we can, but I'd like to know what everyone feels about that
question now that they are looking at the interface already.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
2016-05-02 22:46 ` Andreas Dilger
2016-05-03 15:53 ` David Howells
@ 2016-05-04 22:56 ` Dave Chinner
2016-05-05 0:09 ` NeilBrown
2016-05-06 18:29 ` J. Bruce Fields
2016-05-04 23:56 ` NeilBrown
` (5 subsequent siblings)
8 siblings, 2 replies; 76+ messages in thread
From: Dave Chinner @ 2016-05-04 22:56 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
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.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
` (2 preceding siblings ...)
2016-05-04 22:56 ` Dave Chinner
@ 2016-05-04 23:56 ` NeilBrown
2016-05-08 8:35 ` Christoph Hellwig
` (4 subsequent siblings)
8 siblings, 0 replies; 76+ messages in thread
From: NeilBrown @ 2016-05-04 23:56 UTC (permalink / raw)
To: David Howells, linux-fsdevel
Cc: linux-afs, linux-nfs, samba-technical, linux-kernel, dhowells,
linux-ext4
[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-04 22:56 ` Dave Chinner
@ 2016-05-05 0:09 ` NeilBrown
2016-05-06 18:29 ` J. Bruce Fields
1 sibling, 0 replies; 76+ messages in thread
From: NeilBrown @ 2016-05-05 0:09 UTC (permalink / raw)
To: Dave Chinner, David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-05 0:09 ` NeilBrown
0 siblings, 0 replies; 76+ messages in thread
From: NeilBrown @ 2016-05-05 0:09 UTC (permalink / raw)
To: Dave Chinner, David Howells
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-05 0:09 ` NeilBrown
(?)
@ 2016-05-05 19:48 ` Jeff Layton
2016-05-06 18:07 ` J. Bruce Fields
-1 siblings, 1 reply; 76+ messages in thread
From: Jeff Layton @ 2016-05-05 19:48 UTC (permalink / raw)
To: NeilBrown, Dave Chinner, David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
On Thu, 2016-05-05 at 10:09 +1000, NeilBrown wrote:
> On Thu, May 05 2016, Dave Chinner wrote:
>
> >
> > On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote:
> > >
> > > (4) File creation time (st_btime*), data version (st_version), inode
> > > generation number (st_gen).
> > >
> > > These will be returned if available whether the caller asked for them or
> > > not. The corresponding bits in st_mask will be set or cleared as
> > > appropriate to indicate a valid value.
> > IMO, exposing the inode generation number to anyone is a potential
> > security problem because they are used in file handles.
> "security through obscurity". We have Kerberos working really nicely
> for NFS these days. Do we still care?
>
> What if the generation number were only made available to "root"? Would
> that allay your concerns?
> Would that still be useful?
> We already have name_to_handle_at(). Exposing the generation number
> could/should follow the same rules at that. Or maybe the exposure of
> each field should be guided by the filesystem, depending on (for
> example) whether it is used to provide uniqueness to the filehandle.
>
> >
> >
> > >
> > > If the caller didn't ask for them, then they may be approximated. For
> > > example, NFS won't waste any time updating them from the server, unless
> > > as a byproduct of updating something requested.
> > I would suggest that exposing them from the NFS server is something
> > we most definitely don't want to do because they are the only thing
> > that keeps remote users from guessing filehandles with ease....
> Given that the NFS protocol does not define a "generation number"
> attribute, I think there is no risk for them being exposed from the NFS
> server ... except implicitly within the filehandle of course.
>
> NeilBrown
I don't see a real attack vector here either, but OTOH is there a
potential user of this at the moment? An earlier chunk of the patch
description says:
(7) Inode generation number: Useful for FUSE and userspace NFS servers
[Bernd Schubert]. This was asked for but later deemed unnecessary
with the open-by-handle capability available
...the last bit seems to indicate that we don't really need this
anyway, as most userland servers now work with filehandles from the
kernel.
Maybe leave it out for now? It can always be added later.
--
Jeff Layton <jlayton@poochiereds.net>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-05 0:09 ` NeilBrown
@ 2016-05-05 20:04 ` David Howells
-1 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-05 20:04 UTC (permalink / raw)
To: Jeff Layton
Cc: dhowells, NeilBrown, Dave Chinner, linux-fsdevel, linux-afs,
linux-nfs, samba-technical, linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-05 20:04 ` David Howells
0 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-05 20:04 UTC (permalink / raw)
To: Jeff Layton
Cc: dhowells, NeilBrown, Dave Chinner, linux-fsdevel, linux-afs,
linux-nfs, samba-technical, linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [RFC][PATCH 0/6] Enhanced file stat system call
2016-05-04 13:46 ` Arnd Bergmann
(?)
@ 2016-05-05 22:54 ` Steve French
2016-05-06 2:00 ` Steve French
-1 siblings, 1 reply; 76+ messages in thread
From: Steve French @ 2016-05-05 22:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-afs, linux-nfs, samba-technical, LKML, David Howells,
Deepa Dinamani, linux-fsdevel, linux-ext4
On Wed, May 4, 2016 at 8:46 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 29 April 2016 13:57:36 David Howells wrote:
>> struct statx *buffer);
>>
>> This is an enhanced file stat function that provides a number of useful
>> features, in summary:
>>
>> (1) More information: creation time, data version number, inode
generation
>> number and flags. A subset of these is available through a number of
>> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
>>
>
> I have a question about birthtime/creationtime: As we are gaining a way
> to read this, should we also provide a way to update it using a new
variant
> of the utimensat syscall in order to have 'cp -a' create an identical
copy,
> or is the idea that this is defined as the time that is particular copy
> of the inode was created?
>
> I've discussed this with Deepa in the past, as she is driving the
> convertion of the inode timestamps to timespec64 now, and we will
> need a new version of utimensat for her work as well. I can see good
> reasons either way (allowing updates of btime or disallowing them).
It would help interop with Windows (and presumably Mac) if birth time can
be updated
--
Thanks,
Steve
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-05 20:04 ` David Howells
(?)
@ 2016-05-06 1:39 ` Dave Chinner
-1 siblings, 0 replies; 76+ messages in thread
From: Dave Chinner @ 2016-05-06 1:39 UTC (permalink / raw)
To: David Howells
Cc: Jeff Layton, NeilBrown, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-06 1:39 ` Dave Chinner
0 siblings, 0 replies; 76+ messages in thread
From: Dave Chinner @ 2016-05-06 1:39 UTC (permalink / raw)
To: David Howells
Cc: Jeff Layton, NeilBrown, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-06 1:39 ` Dave Chinner
0 siblings, 0 replies; 76+ messages in thread
From: Dave Chinner @ 2016-05-06 1:39 UTC (permalink / raw)
To: David Howells
Cc: Jeff Layton, NeilBrown, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [RFC][PATCH 0/6] Enhanced file stat system call
2016-05-05 22:54 ` Steve French
@ 2016-05-06 2:00 ` Steve French
2016-05-09 13:09 ` Arnd Bergmann
0 siblings, 1 reply; 76+ messages in thread
From: Steve French @ 2016-05-06 2:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, LKML, linux-ext4, Deepa Dinamani
On Thu, May 5, 2016 at 5:54 PM, Steve French <smfrench@gmail.com> wrote:
> On Wed, May 4, 2016 at 8:46 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Friday 29 April 2016 13:57:36 David Howells wrote:
>>> struct statx *buffer);
>>>
>>> This is an enhanced file stat function that provides a number of useful
>>> features, in summary:
>>>
>>> (1) More information: creation time, data version number, inode
>>> generation
>>> number and flags. A subset of these is available through a number of
>>> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
>>>
>>
>> I have a question about birthtime/creationtime: As we are gaining a way
>> to read this, should we also provide a way to update it using a new
>> variant
>> of the utimensat syscall in order to have 'cp -a' create an identical
>> copy,
>> or is the idea that this is defined as the time that is particular copy
>> of the inode was created?
>>
>> I've discussed this with Deepa in the past, as she is driving the
>> convertion of the inode timestamps to timespec64 now, and we will
>> need a new version of utimensat for her work as well. I can see good
>> reasons either way (allowing updates of btime or disallowing them).
>
It would help interop with Windows (and presumably Mac) if birth time can be
updated
--
Thanks,
Steve
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-05 19:48 ` Jeff Layton
@ 2016-05-06 18:07 ` J. Bruce Fields
0 siblings, 0 replies; 76+ messages in thread
From: J. Bruce Fields @ 2016-05-06 18:07 UTC (permalink / raw)
To: Jeff Layton
Cc: NeilBrown, Dave Chinner, David Howells, linux-fsdevel, linux-afs,
linux-nfs, samba-technical, linux-kernel, linux-ext4
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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-06 18:07 ` J. Bruce Fields
0 siblings, 0 replies; 76+ messages in thread
From: J. Bruce Fields @ 2016-05-06 18:07 UTC (permalink / raw)
To: Jeff Layton
Cc: NeilBrown, Dave Chinner, David Howells, linux-fsdevel, linux-afs,
linux-nfs, samba-technical, linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-04 22:56 ` Dave Chinner
2016-05-05 0:09 ` NeilBrown
@ 2016-05-06 18:29 ` J. Bruce Fields
2016-05-09 1:45 ` Dave Chinner
1 sibling, 1 reply; 76+ messages in thread
From: J. Bruce Fields @ 2016-05-06 18:29 UTC (permalink / raw)
To: Dave Chinner
Cc: David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-08 8:35 ` Christoph Hellwig
0 siblings, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-08 8:35 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
> 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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-08 8:35 ` Christoph Hellwig
0 siblings, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-08 8:35 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA
> 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-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 3/6] statx: Ext4: Return enhanced file attributes
@ 2016-05-08 8:38 ` Christoph Hellwig
0 siblings, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-08 8:38 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
On Fri, Apr 29, 2016 at 01:57:59PM +0100, David Howells wrote:
> (3) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS), setting
> STATX_IOC_FLAGS.
Doesn't look like it is. Which actually is a good thing given how much
of a mess FS_IOC_GETFLAGS is.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 3/6] statx: Ext4: Return enhanced file attributes
@ 2016-05-08 8:38 ` Christoph Hellwig
0 siblings, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-08 8:38 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA
On Fri, Apr 29, 2016 at 01:57:59PM +0100, David Howells wrote:
> (3) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS), setting
> STATX_IOC_FLAGS.
Doesn't look like it is. Which actually is a good thing given how much
of a mess FS_IOC_GETFLAGS is.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use
@ 2016-05-08 8:39 ` Christoph Hellwig
0 siblings, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-08 8:39 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
On Fri, Apr 29, 2016 at 01:58:14PM +0100, David Howells wrote:
> Make windows attributes available for CIFS, NTFS and FAT to use in the
> statx struct. The attribute flags map directly by value to those in the
> CIFS PDU flags. Some of these bits can also be used by JFS, UFS and HPFS.
Err, no way. Not that I disagree that some of these might be useful,
but we should define our own set of flags, which would include the
generic part of the IOC_GETFLAGS flags amd whatever we want to add to
them. And we should probably go for 64-bit flags while we're at it.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use
@ 2016-05-08 8:39 ` Christoph Hellwig
0 siblings, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-08 8:39 UTC (permalink / raw)
To: David Howells
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA
On Fri, Apr 29, 2016 at 01:58:14PM +0100, David Howells wrote:
> Make windows attributes available for CIFS, NTFS and FAT to use in the
> statx struct. The attribute flags map directly by value to those in the
> CIFS PDU flags. Some of these bits can also be used by JFS, UFS and HPFS.
Err, no way. Not that I disagree that some of these might be useful,
but we should define our own set of flags, which would include the
generic part of the IOC_GETFLAGS flags amd whatever we want to add to
them. And we should probably go for 64-bit flags while we're at it.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-06 18:29 ` J. Bruce Fields
@ 2016-05-09 1:45 ` Dave Chinner
2016-05-09 2:46 ` J. Bruce Fields
0 siblings, 1 reply; 76+ messages in thread
From: Dave Chinner @ 2016-05-09 1:45 UTC (permalink / raw)
To: J. Bruce Fields
Cc: David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
[ 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.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-09 1:45 ` Dave Chinner
@ 2016-05-09 2:46 ` J. Bruce Fields
0 siblings, 0 replies; 76+ messages in thread
From: J. Bruce Fields @ 2016-05-09 2:46 UTC (permalink / raw)
To: Dave Chinner
Cc: David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-08 8:35 ` Christoph Hellwig
@ 2016-05-09 12:02 ` Jeff Layton
-1 siblings, 0 replies; 76+ messages in thread
From: Jeff Layton @ 2016-05-09 12:02 UTC (permalink / raw)
To: Christoph Hellwig, David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
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.
--
Jeff Layton <jlayton@poochiereds.net>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-09 12:02 ` Jeff Layton
0 siblings, 0 replies; 76+ messages in thread
From: Jeff Layton @ 2016-05-09 12:02 UTC (permalink / raw)
To: Christoph Hellwig, David Howells
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
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.
--
Jeff Layton <jlayton@poochiereds.net>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-09 12:57 ` David Howells
0 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-09 12:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dhowells, linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-09 12:57 ` David Howells
0 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-09 12:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA
Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.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-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
@ 2016-05-09 13:00 ` David Howells
2016-05-03 15:53 ` David Howells
` (7 subsequent siblings)
8 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-09 13:00 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dhowells, linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-09 13:00 ` David Howells
0 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-09 13:00 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-afs, linux-nfs, samba-technical, linux-kernel, dhowells,
linux-fsdevel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [RFC][PATCH 0/6] Enhanced file stat system call
@ 2016-05-09 13:09 ` Arnd Bergmann
0 siblings, 0 replies; 76+ messages in thread
From: Arnd Bergmann @ 2016-05-09 13:09 UTC (permalink / raw)
To: Steve French
Cc: David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, LKML, linux-ext4, Deepa Dinamani
On Thursday 05 May 2016 21:00:18 Steve French wrote:
> On Thu, May 5, 2016 at 5:54 PM, Steve French <smfrench@gmail.com> wrote:
> > On Wed, May 4, 2016 at 8:46 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Friday 29 April 2016 13:57:36 David Howells wrote:
> >>> struct statx *buffer);
> >>>
> >>> This is an enhanced file stat function that provides a number of useful
> >>> features, in summary:
> >>>
> >>> (1) More information: creation time, data version number, inode
> >>> generation
> >>> number and flags. A subset of these is available through a number of
> >>> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
> >>>
> >>
> >> I have a question about birthtime/creationtime: As we are gaining a way
> >> to read this, should we also provide a way to update it using a new
> >> variant
> >> of the utimensat syscall in order to have 'cp -a' create an identical
> >> copy,
> >> or is the idea that this is defined as the time that is particular copy
> >> of the inode was created?
> >>
> >> I've discussed this with Deepa in the past, as she is driving the
> >> convertion of the inode timestamps to timespec64 now, and we will
> >> need a new version of utimensat for her work as well. I can see good
> >> reasons either way (allowing updates of btime or disallowing them).
> >
> It would help interop with Windows (and presumably Mac) if birth time can be
> updated
Ok, thanks. That is certainly a good reason in favor.
If nothing else comes up, I guess we can prepare a patch for a new
utimensat variant to do this and wait for more comments on that.
Arnd
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [RFC][PATCH 0/6] Enhanced file stat system call
@ 2016-05-09 13:09 ` Arnd Bergmann
0 siblings, 0 replies; 76+ messages in thread
From: Arnd Bergmann @ 2016-05-09 13:09 UTC (permalink / raw)
To: Steve French
Cc: David Howells, linux-fsdevel, linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, samba-technical, LKML,
linux-ext4-u79uwXL29TY76Z2rM5mHXA, Deepa Dinamani
On Thursday 05 May 2016 21:00:18 Steve French wrote:
> On Thu, May 5, 2016 at 5:54 PM, Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Wed, May 4, 2016 at 8:46 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> >> On Friday 29 April 2016 13:57:36 David Howells wrote:
> >>> struct statx *buffer);
> >>>
> >>> This is an enhanced file stat function that provides a number of useful
> >>> features, in summary:
> >>>
> >>> (1) More information: creation time, data version number, inode
> >>> generation
> >>> number and flags. A subset of these is available through a number of
> >>> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
> >>>
> >>
> >> I have a question about birthtime/creationtime: As we are gaining a way
> >> to read this, should we also provide a way to update it using a new
> >> variant
> >> of the utimensat syscall in order to have 'cp -a' create an identical
> >> copy,
> >> or is the idea that this is defined as the time that is particular copy
> >> of the inode was created?
> >>
> >> I've discussed this with Deepa in the past, as she is driving the
> >> convertion of the inode timestamps to timespec64 now, and we will
> >> need a new version of utimensat for her work as well. I can see good
> >> reasons either way (allowing updates of btime or disallowing them).
> >
> It would help interop with Windows (and presumably Mac) if birth time can be
> updated
Ok, thanks. That is certainly a good reason in favor.
If nothing else comes up, I guess we can prepare a patch for a new
utimensat variant to do this and wait for more comments on that.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-09 13:23 ` Trond Myklebust
0 siblings, 0 replies; 76+ messages in thread
From: Trond Myklebust @ 2016-05-09 13:23 UTC (permalink / raw)
To: David Howells, Christoph Hellwig
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
On 5/9/16, 08:57, "linux-nfs-owner@vger.kernel.org on behalf of David Howells" <linux-nfs-owner@vger.kernel.org on behalf of dhowells@redhat.com> wrote:
>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.
The NFSv4 definition for the change attribute (which is mapped to i_version when IS_I_VERSION(inode) is true) is
"A value created by the server that the client can use to determine if
file data, directory contents, or attributes of the object have been
modified. The server may return the object's time_metadata attribute
for this attribute's value, but only if the file system object cannot
be updated more frequently than the resolution of time_metadata."
IOW: it is a value that changes on all data and metadata operations, and with no monotonicity requirement. I’m pretty sure all userspace NFSv4 servers out there would like to access it (e.g. Ganesha, dCache).
>
>> > 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-nfs" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-09 13:23 ` Trond Myklebust
0 siblings, 0 replies; 76+ messages in thread
From: Trond Myklebust @ 2016-05-09 13:23 UTC (permalink / raw)
To: David Howells, Christoph Hellwig
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 4461 bytes --]
On 5/9/16, 08:57, "linux-nfs-owner@vger.kernel.org on behalf of David Howells" <linux-nfs-owner@vger.kernel.org on behalf of dhowells@redhat.com> wrote:
>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.
The NFSv4 definition for the change attribute (which is mapped to i_version when IS_I_VERSION(inode) is true) is
"A value created by the server that the client can use to determine if
file data, directory contents, or attributes of the object have been
modified. The server may return the object's time_metadata attribute
for this attribute's value, but only if the file system object cannot
be updated more frequently than the resolution of time_metadata."
IOW: it is a value that changes on all data and metadata operations, and with no monotonicity requirement. I’m pretty sure all userspace NFSv4 servers out there would like to access it (e.g. Ganesha, dCache).
>
>> > 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-nfs" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±û"žØ^n‡r¡ö¦zË\x1aëh™¨èÚ&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br šê+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹\x1e®w¥¢¸?™¨èÚ&¢)ߢ^[f
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-09 13:23 ` Trond Myklebust
0 siblings, 0 replies; 76+ messages in thread
From: Trond Myklebust @ 2016-05-09 13:23 UTC (permalink / raw)
To: David Howells, Christoph Hellwig
Cc: linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
` (6 preceding siblings ...)
2016-05-09 13:00 ` David Howells
@ 2016-05-09 13:38 ` David Howells
2016-05-10 7:08 ` Christoph Hellwig
2016-05-10 8:43 ` David Howells
2016-05-09 13:40 ` David Howells
8 siblings, 2 replies; 76+ messages in thread
From: David Howells @ 2016-05-09 13:38 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dhowells, linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
` (7 preceding siblings ...)
2016-05-09 13:38 ` David Howells
@ 2016-05-09 13:40 ` David Howells
8 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-09 13:40 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dhowells, linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-10 7:00 ` Christoph Hellwig
0 siblings, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-10 7:00 UTC (permalink / raw)
To: Jeff Layton
Cc: Christoph Hellwig, David Howells, linux-fsdevel, linux-afs,
linux-nfs, samba-technical, linux-kernel, linux-ext4
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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-10 7:00 ` Christoph Hellwig
0 siblings, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-10 7:00 UTC (permalink / raw)
To: Jeff Layton
Cc: Christoph Hellwig, David Howells,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA
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-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-09 12:57 ` David Howells
(?)
(?)
@ 2016-05-10 7:04 ` Christoph Hellwig
-1 siblings, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-10 7:04 UTC (permalink / raw)
To: David Howells
Cc: Christoph Hellwig, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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)
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-09 13:38 ` David Howells
@ 2016-05-10 7:08 ` Christoph Hellwig
2016-05-10 8:43 ` David Howells
1 sibling, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-10 7:08 UTC (permalink / raw)
To: David Howells
Cc: Christoph Hellwig, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-09 12:57 ` David Howells
` (2 preceding siblings ...)
(?)
@ 2016-05-10 8:25 ` David Howells
2016-05-12 9:11 ` Christoph Hellwig
-1 siblings, 1 reply; 76+ messages in thread
From: David Howells @ 2016-05-10 8:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dhowells, linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-09 13:38 ` David Howells
2016-05-10 7:08 ` Christoph Hellwig
@ 2016-05-10 8:43 ` David Howells
2016-05-12 9:12 ` Christoph Hellwig
1 sibling, 1 reply; 76+ messages in thread
From: David Howells @ 2016-05-10 8:43 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dhowells, linux-fsdevel, linux-afs, linux-nfs, samba-technical,
linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-10 7:00 ` Christoph Hellwig
@ 2016-05-10 13:21 ` Jeff Layton
-1 siblings, 0 replies; 76+ messages in thread
From: Jeff Layton @ 2016-05-10 13:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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.
--
Jeff Layton <jlayton@poochiereds.net>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-10 13:21 ` Jeff Layton
0 siblings, 0 replies; 76+ messages in thread
From: Jeff Layton @ 2016-05-10 13:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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.
--
Jeff Layton <jlayton@poochiereds.net>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-10 8:25 ` David Howells
@ 2016-05-12 9:11 ` Christoph Hellwig
2016-05-13 15:28 ` Arnd Bergmann
2016-05-18 10:55 ` David Howells
0 siblings, 2 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-12 9:11 UTC (permalink / raw)
To: David Howells
Cc: Christoph Hellwig, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-10 8:43 ` David Howells
@ 2016-05-12 9:12 ` Christoph Hellwig
0 siblings, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-12 9:12 UTC (permalink / raw)
To: David Howells
Cc: Christoph Hellwig, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [RFC][PATCH 0/6] Enhanced file stat system call
2016-05-09 13:09 ` Arnd Bergmann
@ 2016-05-13 14:28 ` Richard Sharpe
-1 siblings, 0 replies; 76+ messages in thread
From: Richard Sharpe @ 2016-05-13 14:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Steve French, David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, LKML, linux-ext4, Deepa Dinamani
On Mon, May 9, 2016 at 6:09 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 05 May 2016 21:00:18 Steve French wrote:
>> On Thu, May 5, 2016 at 5:54 PM, Steve French <smfrench@gmail.com> wrote:
>> > On Wed, May 4, 2016 at 8:46 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> On Friday 29 April 2016 13:57:36 David Howells wrote:
>> >>> struct statx *buffer);
>> >>>
>> >>> This is an enhanced file stat function that provides a number of useful
>> >>> features, in summary:
>> >>>
>> >>> (1) More information: creation time, data version number, inode
>> >>> generation
>> >>> number and flags. A subset of these is available through a number of
>> >>> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
>> >>>
>> >>
>> >> I have a question about birthtime/creationtime: As we are gaining a way
>> >> to read this, should we also provide a way to update it using a new
>> >> variant
>> >> of the utimensat syscall in order to have 'cp -a' create an identical
>> >> copy,
>> >> or is the idea that this is defined as the time that is particular copy
>> >> of the inode was created?
>> >>
>> >> I've discussed this with Deepa in the past, as she is driving the
>> >> convertion of the inode timestamps to timespec64 now, and we will
>> >> need a new version of utimensat for her work as well. I can see good
>> >> reasons either way (allowing updates of btime or disallowing them).
>> >
>> It would help interop with Windows (and presumably Mac) if birth time can be
>> updated
>
> Ok, thanks. That is certainly a good reason in favor.
>
> If nothing else comes up, I guess we can prepare a patch for a new
> utimensat variant to do this and wait for more comments on that.
>
> Arnd
Isn't there also a strong case for a setattr call that allows us to
atomically set a collection of attributes from userspace?
It would seem that network file systems (the clients) could use such features.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [RFC][PATCH 0/6] Enhanced file stat system call
@ 2016-05-13 14:28 ` Richard Sharpe
0 siblings, 0 replies; 76+ messages in thread
From: Richard Sharpe @ 2016-05-13 14:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Steve French, David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, LKML, linux-ext4, Deepa Dinamani
On Mon, May 9, 2016 at 6:09 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 05 May 2016 21:00:18 Steve French wrote:
>> On Thu, May 5, 2016 at 5:54 PM, Steve French <smfrench@gmail.com> wrote:
>> > On Wed, May 4, 2016 at 8:46 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> On Friday 29 April 2016 13:57:36 David Howells wrote:
>> >>> struct statx *buffer);
>> >>>
>> >>> This is an enhanced file stat function that provides a number of useful
>> >>> features, in summary:
>> >>>
>> >>> (1) More information: creation time, data version number, inode
>> >>> generation
>> >>> number and flags. A subset of these is available through a number of
>> >>> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
>> >>>
>> >>
>> >> I have a question about birthtime/creationtime: As we are gaining a way
>> >> to read this, should we also provide a way to update it using a new
>> >> variant
>> >> of the utimensat syscall in order to have 'cp -a' create an identical
>> >> copy,
>> >> or is the idea that this is defined as the time that is particular copy
>> >> of the inode was created?
>> >>
>> >> I've discussed this with Deepa in the past, as she is driving the
>> >> convertion of the inode timestamps to timespec64 now, and we will
>> >> need a new version of utimensat for her work as well. I can see good
>> >> reasons either way (allowing updates of btime or disallowing them).
>> >
>> It would help interop with Windows (and presumably Mac) if birth time can be
>> updated
>
> Ok, thanks. That is certainly a good reason in favor.
>
> If nothing else comes up, I guess we can prepare a patch for a new
> utimensat variant to do this and wait for more comments on that.
>
> Arnd
Isn't there also a strong case for a setattr call that allows us to
atomically set a collection of attributes from userspace?
It would seem that network file systems (the clients) could use such features.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [RFC][PATCH 0/6] Enhanced file stat system call
2016-05-13 14:28 ` Richard Sharpe
(?)
@ 2016-05-13 15:08 ` Arnd Bergmann
-1 siblings, 0 replies; 76+ messages in thread
From: Arnd Bergmann @ 2016-05-13 15:08 UTC (permalink / raw)
To: Richard Sharpe
Cc: Steve French, David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, LKML, linux-ext4, Deepa Dinamani
On Friday 13 May 2016 07:28:29 Richard Sharpe wrote:
> On Mon, May 9, 2016 at 6:09 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 05 May 2016 21:00:18 Steve French wrote:
> >> On Thu, May 5, 2016 at 5:54 PM, Steve French <smfrench@gmail.com> wrote:
> >> > On Wed, May 4, 2016 at 8:46 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> >> I've discussed this with Deepa in the past, as she is driving the
> >> >> convertion of the inode timestamps to timespec64 now, and we will
> >> >> need a new version of utimensat for her work as well. I can see good
> >> >> reasons either way (allowing updates of btime or disallowing them).
> >> >
> >> It would help interop with Windows (and presumably Mac) if birth time can be
> >> updated
> >
> > Ok, thanks. That is certainly a good reason in favor.
> >
> > If nothing else comes up, I guess we can prepare a patch for a new
> > utimensat variant to do this and wait for more comments on that.
In the meantime I found this LWN article at https://lwn.net/Articles/397442/
Apparently there was a discussion about 6 years ago, without a real
conclusion.
> Isn't there also a strong case for a setattr call that allows us to
> atomically set a collection of attributes from userspace?
>
> It would seem that network file systems (the clients) could use such features.
I had not heard of this before, but that is obviously another option.
Most of the attributes returned by xstat are read-only, but I guess
this would include uid, gid, {a,b,c,m}time and mode (but not size)
along with a 'valid' mask that decides what to set (as in notify_change),
right?
Arnd
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-13 15:28 ` Arnd Bergmann
0 siblings, 0 replies; 76+ messages in thread
From: Arnd Bergmann @ 2016-05-13 15:28 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
@ 2016-05-13 15:28 ` Arnd Bergmann
0 siblings, 0 replies; 76+ messages in thread
From: Arnd Bergmann @ 2016-05-13 15:28 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Howells, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-afs-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA
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-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-12 9:11 ` Christoph Hellwig
2016-05-13 15:28 ` Arnd Bergmann
@ 2016-05-18 10:55 ` David Howells
1 sibling, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-18 10:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dhowells, Arnd Bergmann, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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?
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-13 15:28 ` Arnd Bergmann
(?)
@ 2016-05-23 8:22 ` Christoph Hellwig
-1 siblings, 0 replies; 76+ messages in thread
From: Christoph Hellwig @ 2016-05-23 8:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Christoph Hellwig, David Howells, linux-fsdevel, linux-afs,
linux-nfs, samba-technical, linux-kernel, linux-ext4
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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
2016-05-13 15:28 ` Arnd Bergmann
(?)
(?)
@ 2016-05-23 9:33 ` David Howells
-1 siblings, 0 replies; 76+ messages in thread
From: David Howells @ 2016-05-23 9:33 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dhowells, Arnd Bergmann, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, linux-kernel, linux-ext4
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use
@ 2016-10-03 21:03 ` Steve French
0 siblings, 0 replies; 76+ messages in thread
From: Steve French @ 2016-10-03 21:03 UTC (permalink / raw)
To: Andreas Dilger
Cc: David Howells, linux-fsdevel, linux-afs, linux-nfs,
samba-technical, LKML, linux-ext4
On Mon, May 2, 2016 at 5:52 PM, Andreas Dilger <adilger@dilger.ca> wrote:
> On Apr 29, 2016, at 6:58 AM, David Howells <dhowells@redhat.com> wrote:
>>
>> Make windows attributes available for CIFS, NTFS and FAT to use in the
>> statx struct. The attribute flags map directly by value to those in the
>> CIFS PDU flags. Some of these bits can also be used by JFS, UFS and HPFS.
>>
>> The statx struct acquires:
>>
>> __u32 st_win_attrs;
>
> It seems some of these flags are duplicated with the st_information field,
> and some are duplicate with FS_IOC_GETFLAGS values, and returning the same
> information in multiple ways is confusing.
>
> If these flags are part of the CIFS protocol, and are directly usable by
> Samba then I can understand we wouldn't want to change them once in the
> kernel and then convert them back in userspace, but I'm a bit reluctant
> to have flags only for CIFS/NTFS/FAT that might also be useful for other filesystems. Would we want to be able to get translated st_win_attrs
> flags in ext4 attrs when it is being exported by Samba?
It could be useful to have them in statx in an fs neutral way (and
could be implemented by CIFS/NTFS/FAT and probably NFS), but I am ok
with doing this via file system specific xattrs as we do now: NTFS has
an ntfs specific pseudo-xattr for these and for birth time (and now
cifs with recent patches can return the SMB3 inode attributes,
including the older DOS attributes noted below). Samba server also
stores them in an xattr (although they ndr encode them so it is not
useful to us in the kernel) in local file systems. NFS v4 (and later)
can also return (in theory) some of these flags but they are optional.
>> The value in this is present if STATX_WIN_ATTRS is set.
>>
>> The defined flags in this are:
>>
>> STATX_WIN_ATTR_READONLY
>> STATX_WIN_ATTR_HIDDEN
>> STATX_WIN_ATTR_SYSTEM
>> STATX_WIN_ATTR_DIRECTORY
>
> How does this differ from (st_mode & S_IFMT) == S_IFDIR)?
>
>> STATX_WIN_ATTR_ARCHIVE
>> STATX_WIN_ATTR_NORMAL
>
> How does this differ from (st_mode & S_IFMT) == S_IFREG)?
>
>> STATX_WIN_ATTR_TEMPORARY
>
> How does this differ from STATX_INFO_TEMPORARY?
>
>> STATX_WIN_ATTR_SPARSE_FILE
>> STATX_WIN_ATTR_REPARSE_POINT
>> STATX_WIN_ATTR_COMPRESSED
>> STATX_WIN_ATTR_OFFLINE
>> STATX_WIN_ATTR_NOT_CONTENT_INDEXED
>> STATX_WIN_ATTR_ENCRYPTED
>
> How does this differ from STATX_INFO_ENCRYPTED?
As you noted, directory, compressed, encrypted overlap with existing
posix file type (directory vs. file) and FS_IOC_FLAGS (although
cifs.ko does not allow you to set encrypted yet as we do with
compressed through the IOC flags, I could add a patch for setting the
encrypted flag since it should be trivial as it does not affect
reads/writes/open/close over the network fs since the file would be
only encrypted at rest on the server fs)
--
Thanks,
Steve
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use
@ 2016-10-03 21:03 ` Steve French
0 siblings, 0 replies; 76+ messages in thread
From: Steve French @ 2016-10-03 21:03 UTC (permalink / raw)
To: Andreas Dilger
Cc: David Howells, linux-fsdevel, linux-afs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, samba-technical, LKML,
linux-ext4-u79uwXL29TY76Z2rM5mHXA
On Mon, May 2, 2016 at 5:52 PM, Andreas Dilger <adilger-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org> wrote:
> On Apr 29, 2016, at 6:58 AM, David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> Make windows attributes available for CIFS, NTFS and FAT to use in the
>> statx struct. The attribute flags map directly by value to those in the
>> CIFS PDU flags. Some of these bits can also be used by JFS, UFS and HPFS.
>>
>> The statx struct acquires:
>>
>> __u32 st_win_attrs;
>
> It seems some of these flags are duplicated with the st_information field,
> and some are duplicate with FS_IOC_GETFLAGS values, and returning the same
> information in multiple ways is confusing.
>
> If these flags are part of the CIFS protocol, and are directly usable by
> Samba then I can understand we wouldn't want to change them once in the
> kernel and then convert them back in userspace, but I'm a bit reluctant
> to have flags only for CIFS/NTFS/FAT that might also be useful for other filesystems. Would we want to be able to get translated st_win_attrs
> flags in ext4 attrs when it is being exported by Samba?
It could be useful to have them in statx in an fs neutral way (and
could be implemented by CIFS/NTFS/FAT and probably NFS), but I am ok
with doing this via file system specific xattrs as we do now: NTFS has
an ntfs specific pseudo-xattr for these and for birth time (and now
cifs with recent patches can return the SMB3 inode attributes,
including the older DOS attributes noted below). Samba server also
stores them in an xattr (although they ndr encode them so it is not
useful to us in the kernel) in local file systems. NFS v4 (and later)
can also return (in theory) some of these flags but they are optional.
>> The value in this is present if STATX_WIN_ATTRS is set.
>>
>> The defined flags in this are:
>>
>> STATX_WIN_ATTR_READONLY
>> STATX_WIN_ATTR_HIDDEN
>> STATX_WIN_ATTR_SYSTEM
>> STATX_WIN_ATTR_DIRECTORY
>
> How does this differ from (st_mode & S_IFMT) == S_IFDIR)?
>
>> STATX_WIN_ATTR_ARCHIVE
>> STATX_WIN_ATTR_NORMAL
>
> How does this differ from (st_mode & S_IFMT) == S_IFREG)?
>
>> STATX_WIN_ATTR_TEMPORARY
>
> How does this differ from STATX_INFO_TEMPORARY?
>
>> STATX_WIN_ATTR_SPARSE_FILE
>> STATX_WIN_ATTR_REPARSE_POINT
>> STATX_WIN_ATTR_COMPRESSED
>> STATX_WIN_ATTR_OFFLINE
>> STATX_WIN_ATTR_NOT_CONTENT_INDEXED
>> STATX_WIN_ATTR_ENCRYPTED
>
> How does this differ from STATX_INFO_ENCRYPTED?
As you noted, directory, compressed, encrypted overlap with existing
posix file type (directory vs. file) and FS_IOC_FLAGS (although
cifs.ko does not allow you to set encrypted yet as we do with
compressed through the IOC flags, I could add a patch for setting the
encrypted flag since it should be trivial as it does not affect
reads/writes/open/close over the network fs since the file would be
only encrypted at rest on the server fs)
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 76+ messages in thread
end of thread, other threads:[~2016-10-03 21:04 UTC | newest]
Thread overview: 76+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-29 12:57 [RFC][PATCH 0/6] Enhanced file stat system call David Howells
2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells
2016-05-02 22:46 ` Andreas Dilger
2016-05-02 22:46 ` Andreas Dilger
2016-05-03 15:53 ` David Howells
2016-05-04 22:56 ` Dave Chinner
2016-05-05 0:09 ` NeilBrown
2016-05-05 0:09 ` NeilBrown
2016-05-05 19:48 ` Jeff Layton
2016-05-06 18:07 ` J. Bruce Fields
2016-05-06 18:07 ` J. Bruce Fields
2016-05-05 20:04 ` David Howells
2016-05-05 20:04 ` David Howells
2016-05-06 1:39 ` Dave Chinner
2016-05-06 1:39 ` Dave Chinner
2016-05-06 1:39 ` Dave Chinner
2016-05-06 18:29 ` J. Bruce Fields
2016-05-09 1:45 ` Dave Chinner
2016-05-09 2:46 ` J. Bruce Fields
2016-05-04 23:56 ` NeilBrown
2016-05-08 8:35 ` Christoph Hellwig
2016-05-08 8:35 ` Christoph Hellwig
2016-05-09 12:02 ` Jeff Layton
2016-05-09 12:02 ` Jeff Layton
2016-05-10 7:00 ` Christoph Hellwig
2016-05-10 7:00 ` Christoph Hellwig
2016-05-10 13:21 ` Jeff Layton
2016-05-10 13:21 ` Jeff Layton
2016-05-09 12:57 ` David Howells
2016-05-09 12:57 ` David Howells
2016-05-09 13:23 ` Trond Myklebust
2016-05-09 13:23 ` Trond Myklebust
2016-05-09 13:23 ` Trond Myklebust
2016-05-10 7:04 ` Christoph Hellwig
2016-05-10 8:25 ` David Howells
2016-05-12 9:11 ` Christoph Hellwig
2016-05-13 15:28 ` Arnd Bergmann
2016-05-13 15:28 ` Arnd Bergmann
2016-05-23 8:22 ` Christoph Hellwig
2016-05-23 9:33 ` David Howells
2016-05-18 10:55 ` David Howells
2016-05-09 13:00 ` David Howells
2016-05-09 13:00 ` David Howells
2016-05-09 13:38 ` David Howells
2016-05-10 7:08 ` Christoph Hellwig
2016-05-10 8:43 ` David Howells
2016-05-12 9:12 ` Christoph Hellwig
2016-05-09 13:40 ` David Howells
2016-04-29 12:57 ` [PATCH 2/6] statx: AFS: Return enhanced file attributes David Howells
2016-04-29 12:57 ` [PATCH 3/6] statx: Ext4: " David Howells
2016-05-02 22:48 ` Andreas Dilger
2016-05-03 20:24 ` David Howells
2016-05-03 20:24 ` David Howells
2016-05-08 8:38 ` Christoph Hellwig
2016-05-08 8:38 ` Christoph Hellwig
2016-04-29 12:58 ` [PATCH 4/6] statx: NFS: " David Howells
2016-05-02 22:48 ` Andreas Dilger
2016-04-29 12:58 ` [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use David Howells
2016-05-02 22:52 ` Andreas Dilger
2016-10-03 21:03 ` Steve French
2016-10-03 21:03 ` Steve French
2016-05-03 20:23 ` David Howells
2016-05-08 8:39 ` Christoph Hellwig
2016-05-08 8:39 ` Christoph Hellwig
2016-04-29 12:58 ` [PATCH 6/6] statx: CIFS: Return enhanced attributes David Howells
2016-04-30 21:05 ` [RFC][PATCH 0/6] Enhanced file stat system call Jeff Layton
2016-04-30 21:05 ` Jeff Layton
2016-05-04 13:46 ` Arnd Bergmann
2016-05-04 13:46 ` Arnd Bergmann
2016-05-05 22:54 ` Steve French
2016-05-06 2:00 ` Steve French
2016-05-09 13:09 ` Arnd Bergmann
2016-05-09 13:09 ` Arnd Bergmann
2016-05-13 14:28 ` Richard Sharpe
2016-05-13 14:28 ` Richard Sharpe
2016-05-13 15:08 ` Arnd Bergmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.