aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/filesystems
diff options
context:
space:
mode:
authorMiklos Szeredi <mszeredi@suse.cz>2012-06-05 09:10:17 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2012-07-14 08:33:04 -0400
commitd18e9008c377dc6a6d2166a6840bf3a23a5867fd (patch)
tree6bbb29aea7e931b603bd4cea3cc74a0eda7b6379 /Documentation/filesystems
parent54ef487241e863a6046536ac5b1fcd5d7cde86e5 (diff)
vfs: add i_op->atomic_open()
Add a new inode operation which is called on the last component of an open. Using this the filesystem can look up, possibly create and open the file in one atomic operation. If it cannot perform this (e.g. the file type turned out to be wrong) it may signal this by returning NULL instead of an open struct file pointer. i_op->atomic_open() is only called if the last component is negative or needs lookup. Handling cached positive dentries here doesn't add much value: these can be opened using f_op->open(). If the cached file turns out to be invalid, the open can be retried, this time using ->atomic_open() with a fresh dentry. For now leave the old way of using open intents in lookup and revalidate in place. This will be removed once all the users are converted. David Howells noticed that if ->atomic_open() opens the file but does not create it, handle_truncate() will be called on it even if it is not a regular file. Fix this by checking the file type in this case too. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'Documentation/filesystems')
-rw-r--r--Documentation/filesystems/Locking4
-rw-r--r--Documentation/filesystems/vfs.txt11
2 files changed, 15 insertions, 0 deletions
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 8e2da1e06e3b..8157488c3463 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -62,6 +62,9 @@ ata *);
62 int (*removexattr) (struct dentry *, const char *); 62 int (*removexattr) (struct dentry *, const char *);
63 int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len); 63 int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len);
64 void (*update_time)(struct inode *, struct timespec *, int); 64 void (*update_time)(struct inode *, struct timespec *, int);
65 struct file * (*atomic_open)(struct inode *, struct dentry *,
66 struct opendata *, unsigned open_flag,
67 umode_t create_mode, bool *created);
65 68
66locking rules: 69locking rules:
67 all may block 70 all may block
@@ -89,6 +92,7 @@ listxattr: no
89removexattr: yes 92removexattr: yes
90fiemap: no 93fiemap: no
91update_time: no 94update_time: no
95atomic_open: yes
92 96
93 Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on 97 Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
94victim. 98victim.
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index efd23f481704..beb6e691f70a 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -364,6 +364,9 @@ struct inode_operations {
364 ssize_t (*listxattr) (struct dentry *, char *, size_t); 364 ssize_t (*listxattr) (struct dentry *, char *, size_t);
365 int (*removexattr) (struct dentry *, const char *); 365 int (*removexattr) (struct dentry *, const char *);
366 void (*update_time)(struct inode *, struct timespec *, int); 366 void (*update_time)(struct inode *, struct timespec *, int);
367 struct file * (*atomic_open)(struct inode *, struct dentry *,
368 struct opendata *, unsigned open_flag,
369 umode_t create_mode, bool *created);
367}; 370};
368 371
369Again, all methods are called without any locks being held, unless 372Again, all methods are called without any locks being held, unless
@@ -476,6 +479,14 @@ otherwise noted.
476 an inode. If this is not defined the VFS will update the inode itself 479 an inode. If this is not defined the VFS will update the inode itself
477 and call mark_inode_dirty_sync. 480 and call mark_inode_dirty_sync.
478 481
482 atomic_open: called on the last component of an open. Using this optional
483 method the filesystem can look up, possibly create and open the file in
484 one atomic operation. If it cannot perform this (e.g. the file type
485 turned out to be wrong) it may signal this by returning NULL instead of
486 an open struct file pointer. This method is only called if the last
487 component is negative or needs lookup. Cached positive dentries are
488 still handled by f_op->open().
489
479The Address Space Object 490The Address Space Object
480======================== 491========================
481 492