• L
    Revert "pty: fix the cached path of the pty slave file descriptor in the master" · 143c97cc
    Linus Torvalds 提交于
    This reverts commit c8c03f18.
    
    It turns out that while fixing the ptmx file descriptor to have the
    correct 'struct path' to the associated slave pty is a really good
    thing, it breaks some user space tools for a very annoying reason.
    
    The problem is that /dev/ptmx and its associated slave pty (/dev/pts/X)
    are on different mounts.  That was what caused us to have the wrong path
    in the first place (we would mix up the vfsmount of the 'ptmx' node,
    with the dentry of the pty slave node), but it also means that now while
    we use the right vfsmount, having the pty master open also keeps the pts
    mount busy.
    
    And it turn sout that that makes 'pbuilder' very unhappy, as noted by
    Stefan Lippers-Hollmann:
    
     "This patch introduces a regression for me when using pbuilder
      0.228.7[2] (a helper to build Debian packages in a chroot and to
      create and update its chroots) when trying to umount /dev/ptmx (inside
      the chroot) on Debian/ unstable (full log and pbuilder configuration
      file[3] attached).
    
      [...]
      Setting up build-essential (12.3) ...
      Processing triggers for libc-bin (2.24-15) ...
      I: unmounting dev/ptmx filesystem
      W: Could not unmount dev/ptmx: umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy
              (In some cases useful info about processes that
               use the device is found by lsof(8) or fuser(1).)"
    
    apparently pbuilder tries to unmount the /dev/pts filesystem while still
    holding at least one master node open, which is arguably not very nice,
    but we don't break user space even when fixing other bugs.
    
    So this commit has to be reverted.
    
    I'll try to figure out a way to avoid caching the path to the slave pty
    in the master pty.  The only thing that actually wants that slave pty
    path is the "TIOCGPTPEER" ioctl, and I think we could just recreate the
    path at that time.
    Reported-by: NStefan Lippers-Hollmann <s.l-h@gmx.de>
    Cc: Eric W Biederman <ebiederm@xmission.com>
    Cc: Christian Brauner <christian.brauner@canonical.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    143c97cc
devpts_fs.h 1.0 KB