1. 16 Jul, 2012 1 commit
  2. 27 Jun, 2012 1 commit
  3. 30 Apr, 2012 1 commit
    • Jiri Slaby's avatar
      TTY: n_tty, do not dereference user buffer · 3fa10cc8
      Jiri Slaby authored
      copy_from_read_buf currently copies data to a user buffer and then
      checks if the data is single EOF. But it checks it by accessing the
      user buffer. First, the buffer may be changed by other threads of the
      user program already. Second, it accesses the buffer without any
      checks. It might be write-only for example.
      
      Fix this by inspecting contents of the tty (kernel) buffer instead.
      Note that "n == 1" is necessary, but not sufficient. But we check
      later that there is nothing left by "!tty->read_cnt" condition.
      
      There is still an issue with the current code that EOF being wrapped
      to the start of the circular buffer will result in an inappropriate
      losing of the EOF character. But this is not intended to be fixed by
      this patch.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Reported-by: default avatarEmil Goode <emilgoode@gmail.com>
      Cc: Howard Chu <hyc@symas.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fa10cc8
  4. 28 Mar, 2012 1 commit
  5. 10 Dec, 2011 1 commit
  6. 01 Jul, 2011 1 commit
    • Andrew McGregor's avatar
      tty: fix "IRQ45: nobody cared" · 7b292b4b
      Andrew McGregor authored
      Unthrottling the TTY during close ends up enabling interrupts
      on a device not on the active list, which will never have the
      interrupts cleared.  Doctor, it hurts when I do this.
      
      >>> On 6/2/2011 at 01:56 AM, in message <20110601145608.3e586e16@bob.linux.org.uk>, Alan Cox <alan@linux.intel.com> wrote:
      > On Wed, 01 Jun 2011 10:34:07 +1200
      > "andrew mcgregor" <andrew.mcgregor@alliedtelesis.co.nz> wrote:
      > > The LKML message
      > > http://kerneltrap.org/mailarchive/linux-kernel/2010/2/25/4541847 from
      > > February doesn't seem to have been resolved since.  We struck the
      > > issue, and the patch below (against 2.6.32) fixes it.  Should I
      > > supply a patch against 3.0.0rc?
      >
      > I think that would be sensible. I don't actually see how you hit it as
      > the IRQ ought to be masked by then but it's certainly wrong for n_tty
      > to be calling into check_unthrottle at that point.
      >
      > So yes please send a patch with a suitable Signed-off-by: line to
      > linux-serial and cc GregKH <greg@kroah.com> as well.
      >
      > Alan
      Signed-off-by: default avatarAndrew McGregor <andrew.mcgregor@alliedtelesis.co.nz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      7b292b4b
  7. 07 Jun, 2011 1 commit
  8. 03 Jun, 2011 1 commit
    • Linus Torvalds's avatar
      Revert "tty: make receive_buf() return the amout of bytes received" · 55db4c64
      Linus Torvalds authored
      This reverts commit b1c43f82.
      
      It was broken in so many ways, and results in random odd pty issues.
      
      It re-introduced the buggy schedule_work() in flush_to_ldisc() that can
      cause endless work-loops (see commit a5660b41: "tty: fix endless
      work loop when the buffer fills up").
      
      It also used an "unsigned int" return value fo the ->receive_buf()
      function, but then made multiple functions return a negative error code,
      and didn't actually check for the error in the caller.
      
      And it didn't actually work at all.  BenH bisected down odd tty behavior
      to it:
        "It looks like the patch is causing some major malfunctions of the X
         server for me, possibly related to PTYs.  For example, cat'ing a
         large file in a gnome terminal hangs the kernel for -minutes- in a
         loop of what looks like flush_to_ldisc/workqueue code, (some ftrace
         data in the quoted bits further down).
      
         ...
      
         Some more data: It -looks- like what happens is that the
         flush_to_ldisc work queue entry constantly re-queues itself (because
         the PTY is full ?) and the workqueue thread will basically loop
         forver calling it without ever scheduling, thus starving the consumer
         process that could have emptied the PTY."
      
      which is pretty much exactly the problem we fixed in a5660b41.
      
      Milton Miller pointed out the 'unsigned int' issue.
      Reported-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Reported-by: default avatarMilton Miller <miltonm@bga.com>
      Cc: Stefan Bigler <stefan.bigler@keymile.com>
      Cc: Toby Gray <toby.gray@realvnc.com>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      55db4c64
  9. 23 Apr, 2011 1 commit
  10. 04 Apr, 2011 1 commit
    • Linus Torvalds's avatar
      tty: fix endless work loop when the buffer fills up · a5660b41
      Linus Torvalds authored
      Commit f23eb2b2 ('tty: stop using "delayed_work" in the tty layer')
      ended up causing hung machines on UP with no preemption, because the
      work routine to flip the buffer data to the ldisc would endlessly re-arm
      itself if the destination buffer had filled up.
      
      With the delayed work, that only caused a timer-driving polling of the
      tty state every timer tick, but without the delay we just ended up with
      basically a busy loop instead.
      
      Stop the insane polling, and instead make the code that opens up the
      receive room re-schedule the buffer flip work.  That's what we should
      have been doing anyway.
      
      This same "poll for tty room" issue is almost certainly also the cause
      of excessive kworker activity when idle reported by Dave Jones, who also
      reported "flush_to_ldisc executing 2500 times a second" back in Nov 2010:
      
        http://lkml.org/lkml/2010/11/30/592
      
      which is that silly flushing done every timer tick.  Wasting both power
      and CPU for no good reason.
      Reported-and-tested-by: default avatarAlexander Beregalov <a.beregalov@gmail.com>
      Reported-and-tested-by: default avatarSitsofe Wheeler <sitsofe@yahoo.com>
      Cc: Greg KH <gregkh@suse.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Dave Jones <davej@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a5660b41
  11. 05 Nov, 2010 1 commit
  12. 10 Aug, 2010 1 commit
    • hyc@symas.com's avatar
      tty: Add EXTPROC support for LINEMODE · 26df6d13
      hyc@symas.com authored
      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: default avatarHoward Chu <hyc@symas.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
      26df6d13
  13. 12 Mar, 2010 1 commit
  14. 19 Sep, 2009 2 commits
  15. 05 Sep, 2009 1 commit
    • Linus Torvalds's avatar
      n_tty: do O_ONLCR translation as a single write · 37f81fa1
      Linus Torvalds authored
      When translating CR to CRNL in the n_tty line discipline, we did it as
      two tty_put_char() calls.  Which works, but is stupid, and has caused
      problems before too with bad interactions with the write_room() logic.
      The generic USB serial driver had that problem, for example.
      
      Now the pty layer had similar issues after being moved to the generic
      tty buffering code (in commit d945cb9c:
      "pty: Rework the pty layer to use the normal buffering logic").
      
      So stop doing the silly separate two writes, and do it as a single write
      instead.  That's what the n_tty layer already does for the space
      expansion of tabs (XTABS), and it means that we'll now always have just
      a single write for the CRNL to match the single 'tty_write_room()' test,
      which hopefully means that the next time somebody screws up buffering,
      it won't cause weeks of debugging.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      37f81fa1
  16. 29 Jul, 2009 1 commit
    • OGAWA Hirofumi's avatar
      pty: avoid forcing 'low_latency' tty flag · e043e42b
      OGAWA Hirofumi authored
      We really don't want to mark the pty as a low-latency device, because as
      Alan points out, the ->write method can be called from an IRQ (ppp?),
      and that means we can't use ->low_latency=1 as we take mutexes in the
      low_latency case.
      
      So rather than using low_latency to force the written data to be pushed
      to the ldisc handling at 'write()' time, just make the reader side (or
      the poll function) do the flush when it checks whether there is data to
      be had.
      
      This also fixes the problem with lost data in an emacs compile buffer
      (bugzilla 13815), and we can thus revert the low_latency pty hack
      (commit 3a542974: "pty: quickfix for the
      pty ENXIO timing problems").
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Tested-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      [ Modified to do the tty_flush_to_ldisc() inside input_available_p() so
        that it triggers for both read and poll()  - Linus]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e043e42b
  17. 16 Jul, 2009 1 commit
    • Alan Cox's avatar
      n_tty: Fix echo race · 80770884
      Alan Cox authored
      If a tty in N_TTY mode with echo enabled manages to get itself into a state
      where
      	- echo characters are pending
      	- FASYNC is enabled
      	- tty_write_wakeup is called from either
      		- a device write path (pty)
      		- an IRQ (serial)
      
      then it either deadlocks or explodes taking a mutex in the IRQ path.
      
      On the serial side it is almost impossible to reproduce because you have to
      go from a full serial port to a near empty one with echo characters
      pending. The pty case happens to have become possible to trigger using
      emacs and ptys, the pty changes having created a scenario which shows up
      this bug.
      
      The code path is
      
      	n_tty:process_echoes() (takes mutex)
      	tty_io:tty_put_char()
      	pty:pty_write  (or serial paths)
      	tty_wakeup     (from pty_write or serial IRQ)
      	n_tty_write_wakeup()
      	process_echoes()
      	*KABOOM*
      Signed-off-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      80770884
  18. 11 Jun, 2009 2 commits
  19. 02 Jan, 2009 6 commits
    • Thomas Pfaff's avatar
      tty: N_TTY SIGIO only works for read · ff8cb0fd
      Thomas Pfaff authored
      The N_TTY ldisc layer does not send SIGIO POLL_OUTs correctly when output is
      possible due to flawed handling of the TTY_DO_WRITE_WAKEUP bit. It will
      either send no SIGIOs at all or on every tty wakeup.
      
      The fix is to set the bit when the tty driver write would block and test
      and clear it on write wakeup.
      
      [Merged with existing N_TTY patches and a small buglet fixed -- Alan]
      Signed-off-by: default avatarThomas Pfaff <tpfaff@pcs.com>
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ff8cb0fd
    • Joe Peterson's avatar
      n_tty: Output bells immediately on a full buffer · 7e94b1d9
      Joe Peterson authored
      This patch causes "bell" (^G) characters (invoked when the input buffer
      is full) to be immediately output rather than filling the echo buffer.
      
      This is especially a problem when the tty is stopped and buffers fill, since
      the bells do not serve their purpose of immediate notification that the
      buffer cannot take further input, and they will flush all at once when the
      tty is restarted.
      Signed-off-by: default avatarJoe Peterson <joe@skyrush.com>
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7e94b1d9
    • Joe Peterson's avatar
      n_tty: Fix hanfling of buffer full corner cases · acc71bba
      Joe Peterson authored
      Fix the handling of input characters when the tty buffer is full or nearly
      full.  This includes tests that are done in n_tty_receive_char() and handling
      of PARMRK.
      
      Problems with the buffer-full tests done in receive_char() caused characters to
      be lost at times when the buffer(s) filled.  Also, these full conditions
      would often only be detected with echo on, and PARMRK was not accounted for
      properly in all cases.  One symptom of these problems, in addition to lost
      characters, was early termination from unix commands like tr and cat when
      ^Q was used to break from a stopped tty with full buffers (note that breaking
      out was often previously not possible, due to the pty getting in "gridlock",
      which will be addressed in another patch).  Note space is always reserved
      at the end of the buffer for a newline (or EOF/EOL) in canonical mode.
      Signed-off-by: default avatarJoe Peterson <joe@skyrush.com>
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      acc71bba
    • Joe Peterson's avatar
      n_tty: Fix handling of control characters and continuations · a59c0d6f
      Joe Peterson authored
      Fix process_output_block to detect continuation characters correctly
      and to handle control characters even when O_OLCUC is enabled.  Make
      similar change to do_output_char().
      Signed-off-by: default avatarJoe Peterson <joe@skyrush.com>
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a59c0d6f
    • Alan Cox's avatar
      n_tty: clean up coding style · 300a6204
      Alan Cox authored
      Now the main work is done its polishing time
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      300a6204
    • Joe Peterson's avatar
      n_tty: Fix loss of echoed characters and remove bkl from n_tty · a88a69c9
      Joe Peterson authored
      Fixes the loss of echoed (and other ldisc-generated characters) when
      the tty is stopped or when the driver output buffer is full (happens
      frequently for input during continuous program output, such as ^C)
      and removes the Big Kernel Lock from the N_TTY line discipline.
      
      Adds an "echo buffer" to the N_TTY line discipline that handles all
      ldisc-generated output (including echoed characters).  Along with the
      loss of characters, this also fixes the associated loss of sync between
      tty output and the ldisc state when characters cannot be immediately
      written to the tty driver.
      
      The echo buffer stores (in addition to characters) state operations that need
      to be done at the time of character output (like management of the column
      position).  This allows echo to cooperate correctly with program output,
      since the ldisc state remains consistent with actual characters written.
      
      Since the echo buffer code now isolates the tty column state code
      to the process_out* and process_echoes functions, we can remove the
      Big Kernel Lock (BKL) and replace it with mutex locks.
      
      Highlights are:
      
      * Handles echo (and other ldisc output) when tty driver buffer is full
        - continuous program output can block echo
      * Saves echo when tty is in stopped state (e.g. ^S)
        - (e.g.: ^Q will correctly cause held characters to be released for output)
      * Control character pairs (e.g. "^C") are treated atomically and not
        split up by interleaved program output
      * Line discipline state is kept consistent with characters sent to
        the tty driver
      * Remove the big kernel lock (BKL) from N_TTY line discipline
      Signed-off-by: default avatarJoe Peterson <joe@skyrush.com>
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a88a69c9
  20. 13 Oct, 2008 3 commits
  21. 21 Jul, 2008 1 commit
    • Alan Cox's avatar
      tty: Ldisc revamp · a352def2
      Alan Cox authored
      Move the line disciplines towards a conventional ->ops arrangement.  For
      the moment the actual 'tty_ldisc' struct in the tty is kept as part of
      the tty struct but this can then be changed if it turns out that when it
      all settles down we want to refcount ldiscs separately to the tty.
      
      Pull the ldisc code out of /proc and put it with our ldisc code.
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a352def2
  22. 15 May, 2008 1 commit
    • Ingo Molnar's avatar
      tty: fix BKL related leak and crash · 487ad7ef
      Ingo Molnar authored
      Enabling the BKL to be lockdep tracked uncovered the following
      upstream kernel bug in the tty code, which caused a BKL
      reference leak:
      
        ================================================
        [ BUG: lock held when returning to user space! ]
        ------------------------------------------------
        dmesg/3121 is leaving the kernel with locks still held!
        1 lock held by dmesg/3121:
         #0:  (kernel_mutex){--..}, at: [<c02f34d9>] opost+0x24/0x194
      
      this might explain some of the atomicity warnings and crashes
      that -tip tree testing has been experiencing since the BKL
      was converted back to a spinlock.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      487ad7ef
  23. 30 Apr, 2008 4 commits
  24. 30 Mar, 2008 1 commit
  25. 08 Feb, 2008 1 commit
  26. 06 Feb, 2008 2 commits
    • Joe Peterson's avatar
      Fix IXANY and restart after signal (e.g. ctrl-C) in n_tty line discipline · 54d2a37e
      Joe Peterson authored
      Fix two N_TTY line discipline issues related to resuming a stopped TTY
      (typically done with ctrl-S):
      
      1) Fix handling of character that resumes a stopped TTY (with IXANY)
      
      With "stty ixany", the TTY line discipline would lose the first character
      after the stop, so typing, for example, "hi^Sthere" resulted in "hihere"
      (the 't' would cause the resume after ^S, but it would then be thrown away
      rather than processed as an input character).  This was inconsistent with
      the behavior of other Unix systems.
      
      2) Fix interrupt signal (e.g. ctrl-C) behavior in stopped TTYs
      
      With "stty -ixany" (often the default), interrupt signals were ignored
      in a stopped TTY until the TTY was resumed with the start char (typically
      ctrl-Q), which was inconsistent with the behavior of other Unix systems.
      Signed-off-by: default avatarJoe Peterson <joe@skyrush.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      54d2a37e
    • Joe Peterson's avatar
      tty: enable the echoing of ^C in the N_TTY discipline · ec5b1157
      Joe Peterson authored
      Turn on INTR/QUIT/SUSP echoing in the N_TTY line discipline (e.g.  ctrl-C
      will appear as "^C" if stty echoctl is set and ctrl-C is set as INTR).
      
      Linux seems to be the only unix-like OS (recently I've verified this on
      Solaris, BSD, and Mac OS X) that does *not* behave this way, and I really
      miss this as a good visual confirmation of the interrupt of a program in
      the console or xterm.  I remember this fondly from many Unixs I've used
      over the years as well.  Bringing this to Linux also seems like a good way
      to make it yet more compliant with standard unix-like behavior.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ec5b1157
  27. 19 Oct, 2007 1 commit