diff options
author | Andreas Gruenbacher <agruenba@redhat.com> | 2016-09-29 17:48:44 +0200 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2016-10-07 20:10:44 -0400 |
commit | 6c6ef9f26e598fb977f60935e109cd5b266c941a (patch) | |
tree | ee583d1c81a7f2e3380cc71108f033ff961649eb /Documentation/filesystems/Locking | |
parent | bf3ee71363c0b44acb62f375aea470262ac4210a (diff) | |
download | linux-stable-6c6ef9f26e598fb977f60935e109cd5b266c941a.tar.gz linux-stable-6c6ef9f26e598fb977f60935e109cd5b266c941a.tar.bz2 linux-stable-6c6ef9f26e598fb977f60935e109cd5b266c941a.zip |
xattr: Stop calling {get,set,remove}xattr inode operations
All filesystems that support xattrs by now do so via xattr handlers.
They all define sb->s_xattr, and their getxattr, setxattr, and
removexattr inode operations use the generic inode operations. On
filesystems that don't support xattrs, the xattr inode operations are
all NULL, and sb->s_xattr is also NULL.
This means that we can remove the getxattr, setxattr, and removexattr
inode operations and directly call the generic handlers, or better,
inline expand those handlers into fs/xattr.c.
Filesystems that do not support xattrs on some inodes should clear the
IOP_XATTR i_opflags flag in those inodes. (Right now, some filesystems
have checks to disable xattrs on some inodes in the ->list, ->get, and
->set xattr handler operations instead.) The IOP_XATTR flag is
automatically cleared in inodes of filesystems that don't have xattr
support.
In orangefs, symlinks do have a setxattr iop but no getxattr iop. Add a
check for symlinks to orangefs_inode_getxattr to preserve the current,
weird behavior; that check may not be necessary though.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'Documentation/filesystems/Locking')
-rw-r--r-- | Documentation/filesystems/Locking | 24 |
1 files changed, 18 insertions, 6 deletions
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index d30fb2cb5066..f56b39ee2e54 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -61,10 +61,7 @@ prototypes: int (*get_acl)(struct inode *, int); int (*setattr) (struct dentry *, struct iattr *); int (*getattr) (struct vfsmount *, struct dentry *, struct kstat *); - int (*setxattr) (struct dentry *, const char *,const void *,size_t,int); - ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t); ssize_t (*listxattr) (struct dentry *, char *, size_t); - int (*removexattr) (struct dentry *, const char *); int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len); void (*update_time)(struct inode *, struct timespec *, int); int (*atomic_open)(struct inode *, struct dentry *, @@ -91,15 +88,13 @@ setattr: yes permission: no (may not block if called in rcu-walk mode) get_acl: no getattr: no -setxattr: yes -getxattr: no listxattr: no -removexattr: yes fiemap: no update_time: no atomic_open: yes tmpfile: no + Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on victim. cross-directory ->rename() and rename2() has (per-superblock) @@ -108,6 +103,23 @@ victim. See Documentation/filesystems/directory-locking for more detailed discussion of the locking scheme for directory operations. +----------------------- xattr_handler operations ----------------------- +prototypes: + bool (*list)(struct dentry *dentry); + int (*get)(const struct xattr_handler *handler, struct dentry *dentry, + struct inode *inode, const char *name, void *buffer, + size_t size); + int (*set)(const struct xattr_handler *handler, struct dentry *dentry, + struct inode *inode, const char *name, const void *buffer, + size_t size, int flags); + +locking rules: + all may block + i_mutex(inode) +list: no +get: no +set: yes + --------------------------- super_operations --------------------------- prototypes: struct inode *(*alloc_inode)(struct super_block *sb); |