1. 17 3月, 2017 1 次提交
  2. 02 3月, 2017 2 次提交
  3. 20 1月, 2017 1 次提交
    • A
      tty_port: allow a port to be opened with a tty that has no file handle · ed3f0af8
      Alan Cox 提交于
      Let us create tty objects entirely in kernel space. Untested proposal to
      show why all the ideas around rewriting half the uart stack are not needed.
      
      With this a kernel created non file backed tty object could be used to handle
      data, and set terminal modes. Not all ldiscs can cope with this as N_TTY in
      particular has to work back to the fs/tty layer.
      
      The tty_port code is however otherwise clean of file handles as far as I can
      tell as is the low level tty port write path used by the ldisc, the
      configuration low level interfaces and most of the ldiscs.
      
      Currently you don't have any exposure to see tty hangups because those are
      built around the file layer. However a) it's a fixed port so you probably
      don't care about that b) if you do we can add a callback and c) you almost
      certainly don't want the userspace tear down/rebuild behaviour anyway.
      
      This should however be sufficient if we wanted for example to enumerate all
      the bluetooth bound fixed ports via ACPI and make them directly available.
      It doesn't deal with the case of a user opening a port that's also kernel
      opened and that would need some locking out (so it returned EBUSY if bound
      to a kernel device of some kind). That needs resolving along with how you
      "up" or "down" your new bluetooth device, or enumerate it while providing
      the existing tty API to avoid regressions (and to debug).
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-By: NSebastian Reichel <sre@kernel.org>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed3f0af8
  4. 19 1月, 2017 1 次提交
  5. 01 5月, 2016 3 次提交
  6. 27 4月, 2016 1 次提交
    • L
      devpts: more pty driver interface cleanups · 8ead9dd5
      Linus Torvalds 提交于
      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: NLinus Torvalds <torvalds@linux-foundation.org>
      8ead9dd5
  7. 01 4月, 2016 2 次提交
  8. 07 2月, 2016 1 次提交
  9. 29 1月, 2016 3 次提交
    • P
      tty: Fix ioctl(FIOASYNC) on hungup file · a8f3a297
      Peter Hurley 提交于
      A small race window exists which allows signal-driven async i/o to be
      enabled for the tty when the file ptr has already been hungup and
      signal-driven i/o has been disabled:
      
      CPU 0                                CPU 1
      -----                                ------
      ioctl_fioasync(on)
        filp->f_op->fasync(on)             __tty_hangup()
          tty_fasync(on)                     tty_lock()
            tty_lock()                       ...
              .                              filp->f_op = &hung_up_tty_fops;
            (waiting)                       __tty_fasync(off)
              .                              tty_unlock()
            /* gets tty lock  */
            /* enables FASYNC */
      
      Check the tty has not been hungup while holding tty_lock.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8f3a297
    • P
      tty: Add fasync() hung up file operation · f557474c
      Peter Hurley 提交于
      VFS uses a two-stage check-and-call method for invoking file_operations
      methods, without explicitly snapshotting either the file_operations ptr
      or the function ptr. Since the tty core is one of the few VFS users that
      changes the f_op file_operations ptr of the file descriptor (when the
      tty has been hung up), and since the likelihood of the compiler generating
      a reload of either f_op or the function ptr is basically nil, just define
      a hung up fasync() file operation that returns an error.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f557474c
    • P
      tty, n_tty: Remove fasync() ldisc notification · bee6741c
      Peter Hurley 提交于
      Only the N_TTY line discipline implements the signal-driven i/o
      notification enabled/disabled by fcntl(F_SETFL, O_ASYNC). The ldisc
      fasync() notification is sent to the ldisc when the enable state has
      changed (the tty core is notified via the fasync() VFS file operation).
      
      The N_TTY line discipline used the enable state to change the wakeup
      condition (minimum_to_wake = 1) for notifying the signal handler i/o is
      available. However, just the presence of data is sufficient and necessary
      to signal i/o is available, so changing minimum_to_wake is unnecessary
      (and creates a race condition with read() and poll() which may be
      concurrently updating minimum_to_wake).
      
      Furthermore, since the kill_fasync() VFS helper performs no action if
      the fasync list is empty, calling unconditionally is preferred; if
      signal driven i/o just has been disabled, no signal will be sent by
      kill_fasync() anyway so notification of the change via the ldisc
      fasync() method is superfluous.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bee6741c
  10. 28 1月, 2016 15 次提交
  11. 27 1月, 2016 3 次提交
  12. 14 12月, 2015 7 次提交