Merge branch 'd_real' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs into work.misc

3 files changed, 44 insertions, 146 deletions

diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 08086dc160d3..a38da93865c2 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -20,6 +20,8 @@ prototypes:
         char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
         struct vfsmount *(*d_automount)(struct path *path);
         int (*d_manage)(struct dentry *, bool);
+        struct dentry *(*d_real)(struct dentry *, const struct inode *,
+                                 unsigned int);
 
 locking rules:
                 rename_lock     ->d_lock        may block       rcu-walk
@@ -34,6 +36,7 @@ d_iput:		no		no		yes		no
 d_dname:        no              no              no              no
 d_automount:    no              no              yes             no
 d_manage:       no              no              yes (ref-walk)  maybe
+d_real          no              no              yes             no
 
 --------------------------- inode_operations --------------------------- 
 prototypes:
@@ -66,7 +69,6 @@ prototypes:
                                 struct file *, unsigned open_flag,
                                 umode_t create_mode, int *opened);
         int (*tmpfile) (struct inode *, struct dentry *, umode_t);
-        int (*dentry_open)(struct dentry *, struct file *, const struct cred *);
 
 locking rules:
         all may block
@@ -95,7 +97,6 @@ fiemap:		no
 update_time:    no
 atomic_open:    yes
 tmpfile:        no
-dentry_open:    no
 
         Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
 victim.
diff --git a/Documentation/filesystems/devpts.txt b/Documentation/filesystems/devpts.txt
index 30d2fcb32f72..9f94fe276dea 100644
--- a/Documentation/filesystems/devpts.txt
+++ b/Documentation/filesystems/devpts.txt
@@ -1,141 +1,26 @@
+Each mount of the devpts filesystem is now distinct such that ptys
+and their indicies allocated in one mount are independent from ptys
+and their indicies in all other mounts.
 
-To support containers, we now allow multiple instances of devpts filesystem,
-such that indices of ptys allocated in one instance are independent of indices
-allocated in other instances of devpts.
+All mounts of the devpts filesystem now create a /dev/pts/ptmx node
+with permissions 0000.
 
-To preserve backward compatibility, this support for multiple instances is
-enabled only if:
+To retain backwards compatibility the a ptmx device node (aka any node
+created with "mknod name c 5 2") when opened will look for an instance
+of devpts under the name "pts" in the same directory as the ptmx device
+node.
 
-        - CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, and
-        - '-o newinstance' mount option is specified while mounting devpts
-
-IOW, devpts now supports both single-instance and multi-instance semantics.
-
-If CONFIG_DEVPTS_MULTIPLE_INSTANCES=n, there is no change in behavior and
-this referred to as the "legacy" mode. In this mode, the new mount options
-(-o newinstance and -o ptmxmode) will be ignored with a 'bogus option' message
-on console.
-
-If CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and devpts is mounted without the
-'newinstance' option (as in current start-up scripts) the new mount binds
-to the initial kernel mount of devpts. This mode is referred to as the
-'single-instance' mode and the current, single-instance semantics are
-preserved, i.e PTYs are common across the system.
-
-The only difference between this single-instance mode and the legacy mode
-is the presence of new, '/dev/pts/ptmx' node with permissions 0000, which
-can safely be ignored.
-
-If CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and 'newinstance' option is specified,
-the mount is considered to be in the multi-instance mode and a new instance
-of the devpts fs is created. Any ptys created in this instance are independent
-of ptys in other instances of devpts. Like in the single-instance mode, the
-/dev/pts/ptmx node is present. To effectively use the multi-instance mode,
-open of /dev/ptmx must be a redirected to '/dev/pts/ptmx' using a symlink or
-bind-mount.
-
-Eg: A container startup script could do the following:
-
-        $ chmod 0666 /dev/pts/ptmx
-        $ rm /dev/ptmx
-        $ ln -s pts/ptmx /dev/ptmx
-        $ ns_exec -cm /bin/bash
-
-        # We are now in new container
-
-        $ umount /dev/pts
-        $ mount -t devpts -o newinstance lxcpts /dev/pts
-        $ sshd -p 1234
-
-where 'ns_exec -cm /bin/bash' calls clone() with CLONE_NEWNS flag and execs
-/bin/bash in the child process.  A pty created by the sshd is not visible in
-the original mount of /dev/pts.
+As an option instead of placing a /dev/ptmx device node at /dev/ptmx
+it is possible to place a symlink to /dev/pts/ptmx at /dev/ptmx or
+to bind mount /dev/ptx/ptmx to /dev/ptmx.  If you opt for using
+the devpts filesystem in this manner devpts should be mounted with
+the ptmxmode=0666, or chmod 0666 /dev/pts/ptmx should be called.
 
 Total count of pty pairs in all instances is limited by sysctls:
 kernel.pty.max = 4096           - global limit
-kernel.pty.reserve = 1024       - reserve for initial instance
+kernel.pty.reserve = 1024       - reserved for filesystems mounted from the initial mount namespace
 kernel.pty.nr                   - current count of ptys
 
 Per-instance limit could be set by adding mount option "max=<count>".
 This feature was added in kernel 3.4 together with sysctl kernel.pty.reserve.
 In kernels older than 3.4 sysctl kernel.pty.max works as per-instance limit.
-
-User-space changes
-------------------
-
-In multi-instance mode (i.e '-o newinstance' mount option is specified at least
-once), following user-space issues should be noted.
-
-1. If -o newinstance mount option is never used, /dev/pts/ptmx can be ignored
-   and no change is needed to system-startup scripts.
-
-2. To effectively use multi-instance mode (i.e -o newinstance is specified)
-   administrators or startup scripts should "redirect" open of /dev/ptmx to
-   /dev/pts/ptmx using either a bind mount or symlink.
-
-        $ mount -t devpts -o newinstance devpts /dev/pts
-
-   followed by either
-
-        $ rm /dev/ptmx
-        $ ln -s pts/ptmx /dev/ptmx
-        $ chmod 666 /dev/pts/ptmx
-   or
-        $ mount -o bind /dev/pts/ptmx /dev/ptmx
-
-3. The '/dev/ptmx -> pts/ptmx' symlink is the preferred method since it
-   enables better error-reporting and treats both single-instance and
-   multi-instance mounts similarly.
-
-   But this method requires that system-startup scripts set the mode of
-   /dev/pts/ptmx correctly (default mode is 0000). The scripts can set the
-   mode by, either
-
-        - adding ptmxmode mount option to devpts entry in /etc/fstab, or
-        - using 'chmod 0666 /dev/pts/ptmx'
-
-4. If multi-instance mode mount is needed for containers, but the system
-   startup scripts have not yet been updated, container-startup scripts
-   should bind mount /dev/ptmx to /dev/pts/ptmx to avoid breaking single-
-   instance mounts.
-
-   Or, in general, container-startup scripts should use:
-
-        mount -t devpts -o newinstance -o ptmxmode=0666 devpts /dev/pts
-        if [ ! -L /dev/ptmx ]; then
-                mount -o bind /dev/pts/ptmx /dev/ptmx
-        fi
-
-   When all devpts mounts are multi-instance, /dev/ptmx can permanently be
-   a symlink to pts/ptmx and the bind mount can be ignored.
-
-5. A multi-instance mount that is not accompanied by the /dev/ptmx to
-   /dev/pts/ptmx redirection would result in an unusable/unreachable pty.
-
-        mount -t devpts -o newinstance lxcpts /dev/pts
-
-   immediately followed by:
-
-        open("/dev/ptmx")
-
-    would create a pty, say /dev/pts/7, in the initial kernel mount.
-    But /dev/pts/7 would be invisible in the new mount.
-
-6. The permissions for /dev/pts/ptmx node should be specified when mounting
-   /dev/pts, using the '-o ptmxmode=%o' mount option (default is 0000).
-
-        mount -t devpts -o newinstance -o ptmxmode=0644 devpts /dev/pts
-
-   The permissions can be later be changed as usual with 'chmod'.
-
-        chmod 666 /dev/pts/ptmx
-
-7. A mount of devpts without the 'newinstance' option results in binding to
-   initial kernel mount.  This behavior while preserving legacy semantics,
-   does not provide strict isolation in a container environment. i.e by
-   mounting devpts without the 'newinstance' option, a container could
-   get visibility into the 'host' or root container's devpts.
-   
-   To workaround this and have strict isolation, all mounts of devpts,
-   including the mount in the root container, should use the newinstance
-   option.
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index d4e07c00e18e..70a056fe51a3 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -364,7 +364,6 @@ struct inode_operations {
         int (*atomic_open)(struct inode *, struct dentry *, struct file *,
                         unsigned open_flag, umode_t create_mode, int *opened);
         int (*tmpfile) (struct inode *, struct dentry *, umode_t);
-        int (*dentry_open)(struct dentry *, struct file *, const struct cred *);
 };
 
 Again, all methods are called without any locks being held, unless
@@ -694,13 +693,6 @@ struct address_space_operations {
         but instead uses bmap to find out where the blocks in the file
         are and uses those addresses directly.
 
-  dentry_open: *WARNING: probably going away soon, do not use!* This is an
-        alternative to f_op->open(), the difference is that this method may open
-        a file not necessarily originating from the same filesystem as the one
-        i_op->open() was called on.  It may be useful for stacking filesystems
-        which want to allow native I/O directly on underlying files.
-
-
   invalidatepage: If a page has PagePrivate set, then invalidatepage
         will be called when part or all of the page is to be removed
         from the address space.  This generally corresponds to either a
@@ -936,6 +928,8 @@ struct dentry_operations {
         char *(*d_dname)(struct dentry *, char *, int);
         struct vfsmount *(*d_automount)(struct path *);
         int (*d_manage)(struct dentry *, bool);
+        struct dentry *(*d_real)(struct dentry *, const struct inode *,
+                                 unsigned int);
 };
 
   d_revalidate: called when the VFS needs to revalidate a dentry. This
@@ -1020,6 +1014,14 @@ struct dentry_operations {
         at the end of the buffer, and returns a pointer to the first char.
         dynamic_dname() helper function is provided to take care of this.
 
+        Example :
+
+        static char *pipefs_dname(struct dentry *dent, char *buffer, int buflen)
+        {
+                return dynamic_dname(dentry, buffer, buflen, "pipe:[%lu]",
+                                dentry->d_inode->i_ino);
+        }
+
   d_automount: called when an automount dentry is to be traversed (optional).
         This should create a new VFS mount record and return the record to the
         caller.  The caller is supplied with a path parameter giving the
@@ -1058,13 +1060,23 @@ struct dentry_operations {
         This function is only used if DCACHE_MANAGE_TRANSIT is set on the
         dentry being transited from.
 
-Example :
+  d_real: overlay/union type filesystems implement this method to return one of
+        the underlying dentries hidden by the overlay.  It is used in three
+        different modes:
 
-static char *pipefs_dname(struct dentry *dent, char *buffer, int buflen)
-{
-        return dynamic_dname(dentry, buffer, buflen, "pipe:[%lu]",
-                                dentry->d_inode->i_ino);
-}
+        Called from open it may need to copy-up the file depending on the
+        supplied open flags.  This mode is selected with a non-zero flags
+        argument.  In this mode the d_real method can return an error.
+
+        Called from file_dentry() it returns the real dentry matching the inode
+        argument.  The real dentry may be from a lower layer already copied up,
+        but still referenced from the file.  This mode is selected with a
+        non-NULL inode argument.  This will always succeed.
+
+        With NULL inode and zero flags the topmost real underlying dentry is
+        returned.  This will always succeed.
+
+        This method is never called with both non-NULL inode and non-zero flags.
 
 Each dentry has a pointer to its parent dentry, as well as a hash list
 of child dentries. Child dentries are basically like files in a