Merge branch 'cross-rename' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs

Pull renameat2 system call from Miklos Szeredi:
 "This adds a new syscall, renameat2(), which is the same as renameat()
  but with a flags argument.

  The purpose of extending rename is to add cross-rename, a symmetric
  variant of rename, which exchanges the two files.  This allows
  interesting things, which were not possible before, for example
  atomically replacing a directory tree with a symlink, etc...  This
  also allows overlayfs and friends to operate on whiteouts atomically.

  Andy Lutomirski also suggested a "noreplace" flag, which disables the
  overwriting behavior of rename.

  These two flags, RENAME_EXCHANGE and RENAME_NOREPLACE are only
  implemented for ext4 as an example and for testing"

* 'cross-rename' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
  ext4: add cross rename support
  ext4: rename: split out helper functions
  ext4: rename: move EMLINK check up
  ext4: rename: create ext4_renament structure for local vars
  vfs: add cross-rename
  vfs: lock_two_nondirectories: allow directory args
  security: add flags to rename hooks
  vfs: add RENAME_NOREPLACE flag
  vfs: add renameat2 syscall
  vfs: rename: use common code for dir and non-dir
  vfs: rename: move d_move() up
  vfs: add d_is_dir()

2 files changed, 21 insertions, 1 deletions

diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 5b0c083d7c0e..f424e0e5b46b 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -47,6 +47,8 @@ prototypes:
         int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
         int (*rename) (struct inode *, struct dentry *,
                         struct inode *, struct dentry *);
+        int (*rename2) (struct inode *, struct dentry *,
+                        struct inode *, struct dentry *, unsigned int);
         int (*readlink) (struct dentry *, char __user *,int);
         void * (*follow_link) (struct dentry *, struct nameidata *);
         void (*put_link) (struct dentry *, struct nameidata *, void *);
@@ -78,6 +80,7 @@ mkdir:		yes
 unlink:         yes (both)
 rmdir:          yes (both)      (see below)
 rename:         yes (all)       (see below)
+rename2:        yes (all)       (see below)
 readlink:       no
 follow_link:    no
 put_link:       no
@@ -96,7 +99,8 @@ tmpfile:	no
 
         Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
 victim.
-        cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
+        cross-directory ->rename() and rename2() has (per-superblock)
+->s_vfs_rename_sem.
 
 See Documentation/filesystems/directory-locking for more detailed discussion
 of the locking scheme for directory operations.
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index c53784c119c8..94eb86287bcb 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -347,6 +347,8 @@ struct inode_operations {
         int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
         int (*rename) (struct inode *, struct dentry *,
                         struct inode *, struct dentry *);
+        int (*rename2) (struct inode *, struct dentry *,
+                        struct inode *, struct dentry *, unsigned int);
         int (*readlink) (struct dentry *, char __user *,int);
         void * (*follow_link) (struct dentry *, struct nameidata *);
         void (*put_link) (struct dentry *, struct nameidata *, void *);
@@ -414,6 +416,20 @@ otherwise noted.
   rename: called by the rename(2) system call to rename the object to
         have the parent and name given by the second inode and dentry.
 
+  rename2: this has an additional flags argument compared to rename.
+        If no flags are supported by the filesystem then this method
+        need not be implemented.  If some flags are supported then the
+        filesystem must return -EINVAL for any unsupported or unknown
+        flags.  Currently the following flags are implemented:
+        (1) RENAME_NOREPLACE: this flag indicates that if the target
+        of the rename exists the rename should fail with -EEXIST
+        instead of replacing the target.  The VFS already checks for
+        existence, so for local filesystems the RENAME_NOREPLACE
+        implementation is equivalent to plain rename.
+        (2) RENAME_EXCHANGE: exchange source and target.  Both must
+        exist; this is checked by the VFS.  Unlike plain rename,
+        source and target may be of different type.
+
   readlink: called by the readlink(2) system call. Only required if
         you want to support reading symbolic links