Skip to content
Snippets Groups Projects
  1. Jan 24, 2022
  2. Sep 03, 2019
  3. Jun 20, 2019
  4. May 24, 2019
  5. May 21, 2019
  6. Jan 24, 2019
    • Varad Gautam's avatar
      fs/devpts: always delete dcache dentry-s in dput() · 73052b0d
      Varad Gautam authored
      
      d_delete only unhashes an entry if it is reached with
      dentry->d_lockref.count != 1. Prior to commit 8ead9dd5 ("devpts:
      more pty driver interface cleanups"), d_delete was called on a dentry
      from devpts_pty_kill with two references held, which would trigger the
      unhashing, and the subsequent dputs would release it.
      
      Commit 8ead9dd5 reworked devpts_pty_kill to stop acquiring the second
      reference from d_find_alias, and the d_delete call left the dentries
      still on the hashed list without actually ever being dropped from dcache
      before explicit cleanup. This causes the number of negative dentries for
      devpts to pile up, and an `ls /dev/pts` invocation can take seconds to
      return.
      
      Provide always_delete_dentry() from simple_dentry_operations
      as .d_delete for devpts, to make the dentry be dropped from dcache.
      
      Without this cleanup, the number of dentries in /dev/pts/ can be grown
      arbitrarily as:
      
      `python -c 'import pty; pty.spawn(["ls", "/dev/pts"])'`
      
      A systemtap probe on dcache_readdir to count d_subdirs shows this count
      to increase with each pty spawn invocation above:
      
      probe kernel.function("dcache_readdir") {
          subdirs = &@cast($file->f_path->dentry, "dentry")->d_subdirs;
          p = subdirs;
          p = @cast(p, "list_head")->next;
          i = 0
          while (p != subdirs) {
            p = @cast(p, "list_head")->next;
            i = i+1;
          }
          printf("number of dentries: %d\n", i);
      }
      
      Fixes: 8ead9dd5 ("devpts: more pty driver interface cleanups")
      Signed-off-by: default avatarVarad Gautam <vrd@amazon.de>
      Reported-by: default avatarZheng Wang <wanz@amazon.de>
      Reported-by: default avatarBrandon Schwartz <bsschwar@amazon.de>
      Root-caused-by: default avatarMaximilian Heyne <mheyne@amazon.de>
      Root-caused-by: default avatarNicolas Pernas Maradei <npernas@amazon.de>
      CC: David Woodhouse <dwmw@amazon.co.uk>
      CC: Maximilian Heyne <mheyne@amazon.de>
      CC: Stefan Nuernberger <snu@amazon.de>
      CC: Amit Shah <aams@amazon.de>
      CC: Linus Torvalds <torvalds@linux-foundation.org>
      CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      CC: Al Viro <viro@ZenIV.linux.org.uk>
      CC: Christian Brauner <christian.brauner@ubuntu.com>
      CC: Eric W. Biederman <ebiederm@xmission.com>
      CC: Matthew Wilcox <willy@infradead.org>
      CC: Eric Biggers <ebiggers@google.com>
      CC: <stable@vger.kernel.org> # 4.9+
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      73052b0d
  7. Aug 22, 2018
  8. Mar 14, 2018
    • Christian Brauner's avatar
    • Christian Brauner's avatar
      devpts: resolve devpts bind-mounts · a319b01d
      Christian Brauner authored
      
      Most libcs will still look at /dev/ptmx when opening the master fd of a pty
      device. When /dev/ptmx is a bind-mount of /dev/pts/ptmx and the TIOCGPTPEER
      ioctl() is used to safely retrieve a file descriptor for the slave side of
      the pty based on the master fd, the /proc/self/fd/{0,1,2} symlinks will
      point to /. A very simply reproducer for this issue presupposing a libc
      that uses TIOCGPTPEER in its openpty() implementation is:
      
      unshare --mount
      mount --bind /dev/pts/ptmx /dev/ptmx
      chmod 666 /dev/ptmx
      script
      ls -al /proc/self/fd/0
      
      Having bind-mounts of /dev/pts/ptmx to /dev/ptmx not working correctly is a
      regression. In addition, it is also a fairly common scenario in containers
      employing user namespaces.
      
      The reason for the current failure is that the kernel tries to verify the
      useability of the devpts filesystem without resolving the /dev/ptmx
      bind-mount first. This will lead it to detect that the dentry is escaping
      its bind-mount. The reason is that while the devpts filesystem mounted at
      /dev/pts has the devtmpfs mounted at /dev as its parent mount:
      
      21 -- -- / /dev
      -- 21 -- / /dev/pts
      
      devtmpfs and devpts are on different devices
      
      -- -- 0:6  / /dev
      -- -- 0:20 / /dev/pts
      
      This has the consequence that the pathname of the parent directory of the
      devpts filesystem mount at /dev/pts is /. So if /dev/ptmx is a bind-mount
      of /dev/pts/ptmx then the /dev/ptmx bind-mount and the devpts mount at
      /dev/pts will end up being located on the same device which is recorded in
      the superblock of their vfsmount. This means the parent directory of the
      /dev/ptmx bind-mount will be /ptmx:
      
      -- -- ---- /ptmx /dev/ptmx
      
      Without the bind-mount resolution patch the kernel will now perform the
      bind-mount escape check directly on /dev/ptmx. The function responsible for
      this is devpts_ptmx_path() which calls pts_path() which in turn calls
      path_parent_directory(). Based on the above explanation,
      path_parent_directory() will yield / as the parent directory for the
      /dev/ptmx bind-mount and not the expected /dev. Thus, the kernel detects
      that /dev/ptmx is escaping its bind-mount and will set /proc/<pid>/fd/<nr>
      to /.
      
      This patch changes the logic to first resolve any bind-mounts. After the
      bind-mounts have been resolved (i.e. we have traced it back to the
      associated devpts mount) devpts_ptmx_path() can be called. In order to
      guarantee correct path generation for the slave file descriptor the kernel
      now requires that a pts directory is found in the parent directory of the
      ptmx bind-mount. This implies that when doing bind-mounts the ptmx
      bind-mount and the devpts mount should have a common parent directory. A
      valid example is:
      
      mount -t devpts devpts /dev/pts
      mount --bind /dev/pts/ptmx /dev/ptmx
      
      an invalid example is:
      
      mount -t devpts devpts /dev/pts
      mount --bind /dev/pts/ptmx /ptmx
      
      This allows us to support:
      - calling open on ptmx devices located inside non-standard devpts mounts:
        mount -t devpts devpts /mnt
        master = open("/mnt/ptmx", ...);
        slave = ioctl(master, TIOCGPTPEER, ...);
      - calling open on ptmx devices located outside the devpts mount with a
        common ancestor directory:
        mount -t devpts devpts /dev/pts
        mount --bind /dev/pts/ptmx /dev/ptmx
        master = open("/dev/ptmx", ...);
        slave = ioctl(master, TIOCGPTPEER, ...);
      
      while failing on ptmx devices located outside the devpts mount without a
      common ancestor directory:
        mount -t devpts devpts /dev/pts
        mount --bind /dev/pts/ptmx /ptmx
        master = open("/ptmx", ...);
        slave = ioctl(master, TIOCGPTPEER, ...);
      
      in which case save path generation cannot be guaranteed.
      
      Signed-off-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      Suggested-by: default avatarEric Biederman <ebiederm@xmission.com>
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Reviewed-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a319b01d
    • Christian Brauner's avatar
      devpts: hoist out check for DEVPTS_SUPER_MAGIC · 7d71109d
      Christian Brauner authored
      
      Hoist the check whether we have already found a suitable devpts filesystem
      out of devpts_ptmx_path() in preparation for the devpts bind-mount
      resolution patch. This is a non-functional change.
      
      Signed-off-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      Reviewed-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7d71109d
  9. Jan 31, 2018
  10. Aug 24, 2017
    • Eric W. Biederman's avatar
      pty: Repair TIOCGPTPEER · 311fc65c
      Eric W. Biederman authored
      
      The implementation of TIOCGPTPEER has two issues.
      
      When /dev/ptmx (as opposed to /dev/pts/ptmx) is opened the wrong
      vfsmount is passed to dentry_open.  Which results in the kernel displaying
      the wrong pathname for the peer.
      
      The second is simply by caching the vfsmount and dentry of the peer it leaves
      them open, in a way they were not previously Which because of the inreased
      reference counts can cause unnecessary behaviour differences resulting in
      regressions.
      
      To fix these move the ioctl into tty_io.c at a generic level allowing
      the ioctl to have access to the struct file on which the ioctl is
      being called.  This allows the path of the slave to be derived when
      opening the slave through TIOCGPTPEER instead of requiring the path to
      the slave be cached.  Thus removing the need for caching the path.
      
      A new function devpts_ptmx_path is factored out of devpts_acquire and
      used to implement a function devpts_mntget.   The new function devpts_mntget
      takes a filp to perform the lookup on and fsi so that it can confirm
      that the superblock that is found by devpts_ptmx_path is the proper superblock.
      
      v2: Lots of fixes to make the code actually work
      v3: Suggestions by Linus
          - Removed the unnecessary initialization of filp in ptm_open_peer
          - Simplified devpts_ptmx_path as gotos are no longer required
      
      [ This is the fix for the issue that was reverted in commit
        143c97cc, but this time without breaking 'pbuilder' due to
        increased reference counts   - Linus ]
      
      Fixes: 54ebbfb1 ("tty: add TIOCGPTPEER ioctl")
      Reported-by: default avatarChristian Brauner <christian.brauner@canonical.com>
      Reported-and-tested-by: default avatarStefan Lippers-Hollmann <s.l-h@gmx.de>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      311fc65c
    • Linus Torvalds's avatar
      Revert "pty: fix the cached path of the pty slave file descriptor in the master" · 143c97cc
      Linus Torvalds authored
      
      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: default avatarStefan 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: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      143c97cc
  11. Aug 17, 2017
    • Linus Torvalds's avatar
      pty: fix the cached path of the pty slave file descriptor in the master · c8c03f18
      Linus Torvalds authored
      
      Christian Brauner reported that if you use the TIOCGPTPEER ioctl() to
      get a slave pty file descriptor, the resulting file descriptor doesn't
      look right in /proc/<pid>/fd/<fd>.  In particular, he wanted to use
      readlink() on /proc/self/fd/<fd> to get the pathname of the slave pty
      (basically implementing "ptsname{_r}()").
      
      The reason for that was that we had generated the wrong 'struct path'
      when we create the pty in ptmx_open().
      
      In particular, the dentry was correct, but the vfsmount pointed to the
      mount of the ptmx node. That _can_ be correct - in case you use
      "/dev/pts/ptmx" to open the master - but usually is not.  The normal
      case is to use /dev/ptmx, which then looks up the pts/ directory, and
      then the vfsmount of the ptmx node is obviously the /dev directory, not
      the /dev/pts/ directory.
      
      We actually did have the right vfsmount available, but in the wrong
      place (it gets looked up in 'devpts_acquire()' when we get a reference
      to the pts filesystem), and so ptmx_open() used the wrong mnt pointer.
      
      The end result of this confusion was that the pty worked fine, but when
      if you did TIOCGPTPEER to get the slave side of the pty, end end result
      would also work, but have that dodgy 'struct path'.
      
      And then when doing "d_path()" on to get the pathname, the vfsmount
      would not match the root of the pts directory, and d_path() would return
      an empty pathname thinking that the entry had escaped a bind mount into
      another mount.
      
      This fixes the problem by making devpts_acquire() return the vfsmount
      for the pts filesystem, allowing ptmx_open() to trivially just use the
      right mount for the pts dentry, and create the proper 'struct path'.
      
      Reported-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Acked-by: default avatarEric Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c8c03f18
  12. Sep 28, 2016
  13. Sep 23, 2016
  14. Sep 22, 2016
  15. Sep 03, 2016
    • Linus Torvalds's avatar
      devpts: return NULL pts 'priv' entry for non-devpts nodes · 3e423945
      Linus Torvalds authored
      
      In commit 8ead9dd5 ("devpts: more pty driver interface cleanups") I
      made devpts_get_priv() just return the dentry->fs_data directly.  And
      because I thought it wouldn't happen, I added a warning if you ever saw
      a pts node that wasn't on devpts.
      
      And no, that warning never triggered under any actual real use, but you
      can trigger it by creating nonsensical pts nodes by hand.
      
      So just revert the warning, and make devpts_get_priv() return NULL for
      that case like it used to.
      
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: stable@vger.kernel.org # 4.6+
      Cc: Eric W Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3e423945
  16. Jun 23, 2016
  17. Jun 05, 2016
    • Eric W. Biederman's avatar
      devpts: Make each mount of devpts an independent filesystem. · eedf265a
      Eric W. Biederman authored
      
      The /dev/ptmx device node is changed to lookup the directory entry "pts"
      in the same directory as the /dev/ptmx device node was opened in.  If
      there is a "pts" entry and that entry is a devpts filesystem /dev/ptmx
      uses that filesystem.  Otherwise the open of /dev/ptmx fails.
      
      The DEVPTS_MULTIPLE_INSTANCES configuration option is removed, so that
      userspace can now safely depend on each mount of devpts creating a new
      instance of the filesystem.
      
      Each mount of devpts is now a separate and equal filesystem.
      
      Reserved ttys are now available to all instances of devpts where the
      mounter is in the initial mount namespace.
      
      A new vfs helper path_pts is introduced that finds a directory entry
      named "pts" in the directory of the passed in path, and changes the
      passed in path to point to it.  The helper path_pts uses a function
      path_parent_directory that was factored out of follow_dotdot.
      
      In the implementation of devpts:
       - devpts_mnt is killed as it is no longer meaningful if all mounts of
         devpts are equal.
       - pts_sb_from_inode is replaced by just inode->i_sb as all cached
         inodes in the tty layer are now from the devpts filesystem.
       - devpts_add_ref is rolled into the new function devpts_ptmx.  And the
         unnecessary inode hold is removed.
       - devpts_del_ref is renamed devpts_release and reduced to just a
         deacrivate_super.
       - The newinstance mount option continues to be accepted but is now
         ignored.
      
      In devpts_fs.h definitions for when !CONFIG_UNIX98_PTYS are removed as
      they are never used.
      
      Documentation/filesystems/devices.txt is updated to describe the current
      situation.
      
      This has been verified to work properly on openwrt-15.05, centos5,
      centos6, centos7, debian-6.0.2, debian-7.9, debian-8.2, ubuntu-14.04.3,
      ubuntu-15.10, fedora23, magia-5, mint-17.3, opensuse-42.1,
      slackware-14.1, gentoo-20151225 (13.0?), archlinux-2015-12-01.  With the
      caveat that on centos6 and on slackware-14.1 that there wind up being
      two instances of the devpts filesystem mounted on /dev/pts, the lower
      copy does not end up getting used.
      
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: Peter Anvin <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
      Cc: Jann Horn <jann@thejh.net>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Florian Weimer <fw@deneb.enyo.de>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      eedf265a
  18. Apr 26, 2016
    • Linus Torvalds's avatar
      devpts: more pty driver interface cleanups · 8ead9dd5
      Linus Torvalds authored
      
      This is more prep-work for the upcoming pty changes.  Still just code
      cleanup with no actual semantic changes.
      
      This removes a bunch pointless complexity by just having the slave pty
      side remember the dentry associated with the devpts slave rather than
      the inode.  That allows us to remove all the "look up the dentry" code
      for when we want to remove it again.
      
      Together with moving the tty pointer from "inode->i_private" to
      "dentry->d_fsdata" and getting rid of pointless inode locking, this
      removes about 30 lines of code.  Not only is the end result smaller,
      it's simpler and easier to understand.
      
      The old code, for example, depended on the d_find_alias() to not just
      find the dentry, but also to check that it is still hashed, which in
      turn validated the tty pointer in the inode.
      
      That is a _very_ roundabout way to say "invalidate the cached tty
      pointer when the dentry is removed".
      
      The new code just does
      
      	dentry->d_fsdata = NULL;
      
      in devpts_pty_kill() instead, invalidating the tty pointer rather more
      directly and obviously.  Don't do something complex and subtle when the
      obvious straightforward approach will do.
      
      The rest of the patch (ie apart from code deletion and the above tty
      pointer clearing) is just switching the calling convention to pass the
      dentry or file pointer around instead of the inode.
      
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Peter Anvin <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
      Cc: Jann Horn <jann@thejh.net>
      Cc: Greg KH <greg@kroah.com>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Florian Weimer <fw@deneb.enyo.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8ead9dd5
  19. Apr 18, 2016
    • Linus Torvalds's avatar
      devpts: clean up interface to pty drivers · 67245ff3
      Linus Torvalds authored
      
      This gets rid of the horrible notion of having that
      
          struct inode *ptmx_inode
      
      be the linchpin of the interface between the pty code and devpts.
      
      By de-emphasizing the ptmx inode, a lot of things actually get cleaner,
      and we will have a much saner way forward.  In particular, this will
      allow us to associate with any particular devpts instance at open-time,
      and not be artificially tied to one particular ptmx inode.
      
      The patch itself is actually fairly straightforward, and apart from some
      locking and return path cleanups it's pretty mechanical:
      
       - the interfaces that devpts exposes all take "struct pts_fs_info *"
         instead of "struct inode *ptmx_inode" now.
      
         NOTE! The "struct pts_fs_info" thing is a completely opaque structure
         as far as the pty driver is concerned: it's still declared entirely
         internally to devpts. So the pty code can't actually access it in any
         way, just pass it as a "cookie" to the devpts code.
      
       - the "look up the pts fs info" is now a single clear operation, that
         also does the reference count increment on the pts superblock.
      
         So "devpts_add/del_ref()" is gone, and replaced by a "lookup and get
         ref" operation (devpts_get_ref(inode)), along with a "put ref" op
         (devpts_put_ref()).
      
       - the pty master "tty->driver_data" field now contains the pts_fs_info,
         not the ptmx inode.
      
       - because we don't care about the ptmx inode any more as some kind of
         base index, the ref counting can now drop the inode games - it just
         gets the ref on the superblock.
      
       - the pts_fs_info now has a back-pointer to the super_block. That's so
         that we can easily look up the information we actually need. Although
         quite often, the pts fs info was actually all we wanted, and not having
         to look it up based on some magical inode makes things more
         straightforward.
      
      In particular, now that "devpts_get_ref(inode)" operation should really
      be the *only* place we need to look up what devpts instance we're
      associated with, and we do it exactly once, at ptmx_open() time.
      
      The other side of this is that one ptmx node could now be associated
      with multiple different devpts instances - you could have a single
      /dev/ptmx node, and then have multiple mount namespaces with their own
      instances of devpts mounted on /dev/pts/.  And that's all perfectly sane
      in a model where we just look up the pts instance at open time.
      
      This will eventually allow us to get rid of our odd single-vs-multiple
      pts instance model, but this patch in itself changes no semantics, only
      an internal binding model.
      
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Peter Anvin <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
      Cc: Jann Horn <jann@thejh.net>
      Cc: Greg KH <greg@kroah.com>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Florian Weimer <fw@deneb.enyo.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      67245ff3
  20. Feb 07, 2016
    • Herton R. Krzesinski's avatar
      pty: make sure super_block is still valid in final /dev/tty close · 1f55c718
      Herton R. Krzesinski authored
      
      Considering current pty code and multiple devpts instances, it's possible
      to umount a devpts file system while a program still has /dev/tty opened
      pointing to a previosuly closed pty pair in that instance. In the case all
      ptmx and pts/N files are closed, umount can be done. If the program closes
      /dev/tty after umount is done, devpts_kill_index will use now an invalid
      super_block, which was already destroyed in the umount operation after
      running ->kill_sb. This is another "use after free" type of issue, but now
      related to the allocated super_block instance.
      
      To avoid the problem (warning at ida_remove and potential crashes) for
      this specific case, I added two functions in devpts which grabs additional
      references to the super_block, which pty code now uses so it makes sure
      the super block structure is still valid until pty shutdown is done.
      I also moved the additional inode references to the same functions, which
      also covered similar case with inode being freed before /dev/tty final
      close/shutdown.
      
      Signed-off-by: default avatarHerton R. Krzesinski <herton@redhat.com>
      Cc: stable@vger.kernel.org # 2.6.29+
      Reviewed-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f55c718
  21. Jan 22, 2016
    • Al Viro's avatar
      wrappers for ->i_mutex access · 5955102c
      Al Viro authored
      
      parallel to mutex_{lock,unlock,trylock,is_locked,lock_nested},
      inode_foo(inode) being mutex_foo(&inode->i_mutex).
      
      Please, use those for access to ->i_mutex; over the coming cycle
      ->i_mutex will become rwsem, with ->lookup() done with it held
      only shared.
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      5955102c
  22. Jul 01, 2015
  23. Apr 15, 2015
  24. Jun 06, 2014
  25. Mar 13, 2014
    • Theodore Ts'o's avatar
      fs: push sync_filesystem() down to the file system's remount_fs() · 02b9984d
      Theodore Ts'o authored
      
      Previously, the no-op "mount -o mount /dev/xxx" operation when the
      file system is already mounted read-write causes an implied,
      unconditional syncfs().  This seems pretty stupid, and it's certainly
      documented or guaraunteed to do this, nor is it particularly useful,
      except in the case where the file system was mounted rw and is getting
      remounted read-only.
      
      However, it's possible that there might be some file systems that are
      actually depending on this behavior.  In most file systems, it's
      probably fine to only call sync_filesystem() when transitioning from
      read-write to read-only, and there are some file systems where this is
      not needed at all (for example, for a pseudo-filesystem or something
      like romfs).
      
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Artem Bityutskiy <dedekind1@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Cc: Jan Kara <jack@suse.cz>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Anders Larsen <al@alarsen.net>
      Cc: Phillip Lougher <phillip@squashfs.org.uk>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: Petr Vandrovec <petr@vandrovec.name>
      Cc: xfs@oss.sgi.com
      Cc: linux-btrfs@vger.kernel.org
      Cc: linux-cifs@vger.kernel.org
      Cc: samba-technical@lists.samba.org
      Cc: codalist@coda.cs.cmu.edu
      Cc: linux-ext4@vger.kernel.org
      Cc: linux-f2fs-devel@lists.sourceforge.net
      Cc: fuse-devel@lists.sourceforge.net
      Cc: cluster-devel@redhat.com
      Cc: linux-mtd@lists.infradead.org
      Cc: jfs-discussion@lists.sourceforge.net
      Cc: linux-nfs@vger.kernel.org
      Cc: linux-nilfs@vger.kernel.org
      Cc: linux-ntfs-dev@lists.sourceforge.net
      Cc: ocfs2-devel@oss.oracle.com
      Cc: reiserfs-devel@vger.kernel.org
      02b9984d
  26. Nov 13, 2013
  27. Mar 07, 2013
Loading