1. 07 3月, 2015 1 次提交
    • J
      TTY: fix tty_wait_until_sent on 64-bit machines · 79fbf4a5
      Johan Hovold 提交于
      Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an
      infinite timeout (0) would be passed to the underlying tty-driver's
      wait_until_sent-operation as a negative timeout (-1), causing it to
      return immediately.
      
      This manifests itself for example as tcdrain() returning immediately,
      drivers not honouring the drain flags when setting terminal attributes,
      or even dropped data on close as a requested infinite closing-wait
      timeout would be ignored.
      
      The first symptom  was reported by Asier LLANO who noted that tcdrain()
      returned prematurely when using the ftdi_sio usb-serial driver.
      
      Fix this by passing 0 rather than MAX_SCHEDULE_TIMEOUT (LONG_MAX) to the
      underlying tty driver.
      
      Note that the serial-core wait_until_sent-implementation is not affected
      by this bug due to a lucky chance (comparison to an unsigned maximum
      timeout), and neither is the cyclades one that had an explicit check for
      negative timeouts, but all other tty drivers appear to be affected.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: stable <stable@vger.kernel.org>	# v2.6.12
      Reported-by: NZIV-Asier Llano Palacios <asier.llano@cgglobal.com>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79fbf4a5
  2. 03 2月, 2015 1 次提交
  3. 06 11月, 2014 3 次提交
  4. 24 9月, 2014 3 次提交
  5. 09 9月, 2014 1 次提交
  6. 26 9月, 2013 1 次提交
  7. 24 7月, 2013 2 次提交
  8. 16 4月, 2013 1 次提交
  9. 19 3月, 2013 3 次提交
    • P
      tty: Fix recursive deadlock in tty_perform_flush() · e7f3880c
      Peter Hurley 提交于
      tty_perform_flush() can deadlock when called while holding
      a line discipline reference. By definition, all ldisc drivers
      hold a ldisc reference, so calls originating from ldisc drivers
      must not block for a ldisc reference.
      
      The deadlock can occur when:
        CPU 0                    |  CPU 1
                                 |
      tty_ldisc_ref(tty)         |
      ....                       | <line discipline halted>
      tty_ldisc_ref_wait(tty)    |
                                 |
      
      CPU 0 cannot progess because it cannot obtain an ldisc reference
      with the line discipline has been halted (thus no new references
      are granted).
      CPU 1 cannot progress because an outstanding ldisc reference
      has not been released.
      
      An in-tree call-tree audit of tty_perform_flush() [1] shows 5
      ldisc drivers calling tty_perform_flush() indirectly via
      n_tty_ioctl_helper() and 2 ldisc drivers calling directly.
      A single tty driver safely uses the function.
      
      [1]
      Recursive usage:
      
      /* These functions are line discipline ioctls and thus
       * recursive wrt line discipline references */
      
      tty_perform_flush() - ./drivers/tty/tty_ioctl.c
          n_tty_ioctl_helper()
              hci_uart_tty_ioctl(default) - drivers/bluetooth/hci_ldisc.c (N_HCI)
              n_hdlc_tty_ioctl(default) - drivers/tty/n_hdlc.c (N_HDLC)
              gsmld_ioctl(default) - drivers/tty/n_gsm.c (N_GSM0710)
              n_tty_ioctl(default) - drivers/tty/n_tty.c (N_TTY)
              gigaset_tty_ioctl(default) - drivers/isdn/gigaset/ser-gigaset.c (N_GIGASET_M101)
          ppp_synctty_ioctl(TCFLSH) - drivers/net/ppp/pps_synctty.c
          ppp_asynctty_ioctl(TCFLSH) - drivers/net/ppp/ppp_async.c
      
      Non-recursive use:
      
      tty_perform_flush() - drivers/tty/tty_ioctl.c
          ipw_ioctl(TCFLSH) - drivers/tty/ipwireless/tty.c
             /* This function is a tty i/o ioctl method, which
              * is invoked by tty_ioctl() */
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e7f3880c
    • J
      TTY: do not warn about setting speed via SPD_* · 6865ff22
      Jiri Slaby 提交于
      The warning is there since 2.1.69 and we have not seen anybody
      reporting it in the past decade. Remove the warning now.
      
      tty_get_baud_rate can now be inline. This gives us one less
      EXPORT_SYMBOL.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6865ff22
    • P
      tty: Add safe tty throttle/unthrottle functions · 70bc1264
      Peter Hurley 提交于
      The tty driver can become stuck throttled due to race conditions
      between throttle and unthrottle, when the decision to throttle
      or unthrottle is conditional. The following example helps to
      illustrate the race:
      
        CPU 0                        |  CPU 1
                                     |
      if (condition A)               |
                                     | <processing such that A not true>
                                     | if (!condition A)
                                     |     unthrottle()
          throttle()                 |
                                     |
      
      Note the converse is also possible; ie.,
      
        CPU 0                        |  CPU 1
                                     |
                                     | if (!condition A)
      <processing such that A true>  |
      if (condition A)               |
          throttle()                 |
                                     |     unthrottle()
                                     |
      
      Add new throttle/unthrottle functions based on the familiar model
      of task state and schedule/wake. For example,
      
          while (1) {
              tty_set_flow_change(tty, TTY_THROTTLE_SAFE);
              if (!condition)
                  break;
              if (!tty_throttle_safe(tty))
                  break;
          }
          __tty_set_flow_change(tty, 0);
      
      In this example, if an unthrottle occurs after the condition is
      evaluated but before tty_throttle_safe(), then tty_throttle_safe()
      will return non-zero, looping and forcing the re-evaluation of
      condition.
      Reported-by: NVincent Pillet <vincentx.pillet@intel.com>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      70bc1264
  10. 05 2月, 2013 1 次提交
  11. 19 1月, 2013 1 次提交
    • I
      tty: Add driver unthrottle in ioctl(...,TCFLSH,..). · a1bf9584
      Ilya Zykov 提交于
      Regression 'tty: fix "IRQ45: nobody cared"'
      Regression commit 7b292b4b
      
        Function reset_buffer_flags() also invoked during the ioctl(...,TCFLSH,..).
      At the time of request we can have full buffers and throttled driver too.
      If we don't unthrottle driver, we can get forever throttled driver, because,
      after request, we will have empty buffers and throttled driver and
      there is no place to unthrottle driver.
      It simple reproduce with "pty" pair then one side sleep on tty->write_wait,
      and other side do ioctl(...,TCFLSH,..). Then there is no place to do writers wake up.
      Signed-off-by: NIlya Zykov <ilya@ilyx.ru>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1bf9584
  12. 26 10月, 2012 1 次提交
  13. 18 7月, 2012 1 次提交
  14. 17 7月, 2012 1 次提交
  15. 29 3月, 2012 1 次提交
  16. 19 10月, 2011 1 次提交
    • T
      tty: Support compat_ioctl get/set termios_locked · 8193c429
      Thomas Meyer 提交于
      When running a Fedora 15 (x86) on an x86_64 kernel, in the boot process
      plymouthd complains about those two missing ioctls:
      [    2.581783] ioctl32(plymouthd:186): Unknown cmd fd(10) cmd(00005457){t:'T';sz:0} arg(ffb6a5d0) on /dev/tty1
      [    2.581803] ioctl32(plymouthd:186): Unknown cmd fd(10) cmd(00005456){t:'T';sz:0} arg(ffb6a680) on /dev/tty1
      
      both ioctl functions work on the 'struct termios' resp. 'struct termios2',
      which has the same size (36 bytes resp. 44 bytes) on x86 and x86_64,
      so it's just a matter of converting the pointer from userland.
      Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@google.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8193c429
  17. 20 4月, 2011 1 次提交
  18. 12 4月, 2011 1 次提交
  19. 31 3月, 2011 1 次提交
  20. 18 2月, 2011 1 次提交
  21. 05 11月, 2010 1 次提交
  22. 11 8月, 2010 1 次提交
    • H
      tty: Add EXTPROC support for LINEMODE · 26df6d13
      hyc@symas.com 提交于
      This patch is against the 2.6.34 source.
      
      Paraphrased from the 1989 BSD patch by David Borman @ cray.com:
      
           These are the changes needed for the kernel to support
           LINEMODE in the server.
      
           There is a new bit in the termios local flag word, EXTPROC.
           When this bit is set, several aspects of the terminal driver
           are disabled.  Input line editing, character echo, and mapping
           of signals are all disabled.  This allows the telnetd to turn
           off these functions when in linemode, but still keep track of
           what state the user wants the terminal to be in.
      
           New ioctl:
               TIOCSIG         Generate a signal to processes in the
                               current process group of the pty.
      
           There is a new mode for packet driver, the TIOCPKT_IOCTL bit.
           When packet mode is turned on in the pty, and the EXTPROC bit
           is set, then whenever the state of the pty is changed, the
           next read on the master side of the pty will have the TIOCPKT_IOCTL
           bit set.  This allows the process on the server side of the pty
           to know when the state of the terminal has changed; it can then
           issue the appropriate ioctl to retrieve the new state.
      
      Since the original BSD patches accompanied the source code for telnet
      I've left that reference here, but obviously the feature is useful for
      any remote terminal protocol, including ssh.
      
      The corresponding feature has existed in the BSD tty driver since 1989.
      For historical reference, a good copy of the relevant files can be found
      here:
      
      http://anonsvn.mit.edu/viewvc/krb5/trunk/src/appl/telnet/?pathrev=17741Signed-off-by: NHoward Chu <hyc@symas.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      26df6d13
  23. 09 11月, 2009 1 次提交
  24. 20 9月, 2009 1 次提交
  25. 13 7月, 2009 1 次提交
  26. 17 6月, 2009 1 次提交
  27. 11 6月, 2009 2 次提交
    • A
      tty: Untangle termios and mm mutex dependencies · 26a2e20f
      Alan Cox 提交于
      Although this doesn't cause any problems it could potentially do so for
      future mmap using devices. No real work is needed to sort it out so untangle
      it before it causes problems
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26a2e20f
    • A
      tty: throttling race fix · 38db8979
      Alan Cox 提交于
      The tty throttling code can race due to the lock drops. It takes very high
      loads but this has been observed and verified by Rob Duncan.
      
      The basic problem is that on an SMP box we can go
      
      	CPU #1				CPU #2
      	need to throttle ?
      	suppose we should		buffer space cleared
      					are we throttled
      					yes ? - unthrottle
      	call throttle method
      
      This changeet take the termios lock to protect against this. The termios
      lock isn't the initial obvious candidate but many implementations of throttle
      methods already need to poke around their own termios structures (and nobody
      really locks them against a racing change of flow control).
      
      This does mean that anyone who is setting tty->low_latency = 1 and then
      calling tty_flip_buffer_push from their unthrottle method is going to end up
      collapsing in a pile of locks. However we've removed all the known bogus
      users of low_latency = 1 and such use isn't safe anyway for other reasons so
      catching it would be an improvement.
      Signed-off-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      38db8979
  28. 16 1月, 2009 1 次提交
  29. 14 10月, 2008 4 次提交