1. 05 11月, 2010 1 次提交
  2. 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
  3. 13 3月, 2010 1 次提交
  4. 20 9月, 2009 2 次提交
  5. 06 9月, 2009 1 次提交
    • L
      n_tty: do O_ONLCR translation as a single write · 37f81fa1
      Linus Torvalds 提交于
      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: NLinus Torvalds <torvalds@linux-foundation.org>
      37f81fa1
  6. 30 7月, 2009 1 次提交
    • O
      pty: avoid forcing 'low_latency' tty flag · e043e42b
      OGAWA Hirofumi 提交于
      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: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Tested-by: NAneesh 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: NLinus Torvalds <torvalds@linux-foundation.org>
      e043e42b
  7. 17 7月, 2009 1 次提交
    • A
      n_tty: Fix echo race · 80770884
      Alan Cox 提交于
      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: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      80770884
  8. 11 6月, 2009 2 次提交
  9. 03 1月, 2009 6 次提交
    • T
      tty: N_TTY SIGIO only works for read · ff8cb0fd
      Thomas Pfaff 提交于
      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: NThomas Pfaff <tpfaff@pcs.com>
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ff8cb0fd
    • J
      n_tty: Output bells immediately on a full buffer · 7e94b1d9
      Joe Peterson 提交于
      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: NJoe Peterson <joe@skyrush.com>
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7e94b1d9
    • J
      n_tty: Fix hanfling of buffer full corner cases · acc71bba
      Joe Peterson 提交于
      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: NJoe Peterson <joe@skyrush.com>
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      acc71bba
    • J
      n_tty: Fix handling of control characters and continuations · a59c0d6f
      Joe Peterson 提交于
      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: NJoe Peterson <joe@skyrush.com>
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a59c0d6f
    • A
      n_tty: clean up coding style · 300a6204
      Alan Cox 提交于
      Now the main work is done its polishing time
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      300a6204
    • J
      n_tty: Fix loss of echoed characters and remove bkl from n_tty · a88a69c9
      Joe Peterson 提交于
      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: NJoe Peterson <joe@skyrush.com>
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a88a69c9
  10. 14 10月, 2008 3 次提交
  11. 21 7月, 2008 1 次提交
    • A
      tty: Ldisc revamp · a352def2
      Alan Cox 提交于
      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: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a352def2
  12. 16 5月, 2008 1 次提交
    • I
      tty: fix BKL related leak and crash · 487ad7ef
      Ingo Molnar 提交于
      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: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      487ad7ef
  13. 30 4月, 2008 4 次提交
  14. 31 3月, 2008 1 次提交
  15. 09 2月, 2008 1 次提交
  16. 07 2月, 2008 2 次提交
    • J
      Fix IXANY and restart after signal (e.g. ctrl-C) in n_tty line discipline · 54d2a37e
      Joe Peterson 提交于
      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: NJoe Peterson <joe@skyrush.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      54d2a37e
    • J
      tty: enable the echoing of ^C in the N_TTY discipline · ec5b1157
      Joe Peterson 提交于
      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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ec5b1157
  17. 20 10月, 2007 1 次提交
  18. 17 7月, 2007 2 次提交
    • M
      Audit: add TTY input auditing · 522ed776
      Miloslav Trmac 提交于
      Add TTY input auditing, used to audit system administrator's actions.  This is
      required by various security standards such as DCID 6/3 and PCI to provide
      non-repudiation of administrator's actions and to allow a review of past
      actions if the administrator seems to overstep their duties or if the system
      becomes misconfigured for unknown reasons.  These requirements do not make it
      necessary to audit TTY output as well.
      
      Compared to an user-space keylogger, this approach records TTY input using the
      audit subsystem, correlated with other audit events, and it is completely
      transparent to the user-space application (e.g.  the console ioctls still
      work).
      
      TTY input auditing works on a higher level than auditing all system calls
      within the session, which would produce an overwhelming amount of mostly
      useless audit events.
      
      Add an "audit_tty" attribute, inherited across fork ().  Data read from TTYs
      by process with the attribute is sent to the audit subsystem by the kernel.
      The audit netlink interface is extended to allow modifying the audit_tty
      attribute, and to allow sending explanatory audit events from user-space (for
      example, a shell might send an event containing the final command, after the
      interactive command-line editing and history expansion is performed, which
      might be difficult to decipher from the TTY input alone).
      
      Because the "audit_tty" attribute is inherited across fork (), it would be set
      e.g.  for sshd restarted within an audited session.  To prevent this, the
      audit_tty attribute is cleared when a process with no open TTY file
      descriptors (e.g.  after daemon startup) opens a TTY.
      
      See https://www.redhat.com/archives/linux-audit/2007-June/msg00000.html for a
      more detailed rationale document for an older version of this patch.
      
      [akpm@linux-foundation.org: build fix]
      Signed-off-by: NMiloslav Trmac <mitr@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Paul Fulghum <paulkf@microgate.com>
      Cc: Casey Schaufler <casey@schaufler-ca.com>
      Cc: Steve Grubb <sgrubb@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      522ed776
    • A
      Prevent an O_NDELAY writer from blocking when a tty write is blocked by the tty atomic writer mutex · 9c1729db
      Alan Cox 提交于
      Without this a tty write could block if a previous blocking tty write was
      in progress on the same tty and blocked by a line discipline or hardware
      event.  Originally found and reported by Dave Johnson.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Acked-by: NDave Johnson <djohnson+linux-kernel@sw.starentnetworks.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9c1729db
  19. 01 6月, 2007 1 次提交
  20. 11 5月, 2007 1 次提交
  21. 13 2月, 2007 2 次提交
  22. 14 12月, 2006 1 次提交
  23. 09 12月, 2006 1 次提交
    • A
      [PATCH] tty: switch to ktermios · 606d099c
      Alan Cox 提交于
      This is the grungy swap all the occurrences in the right places patch that
      goes with the updates.  At this point we have the same functionality as
      before (except that sgttyb() returns speeds not zero) and are ready to
      begin turning new stuff on providing nobody reports lots of bugs
      
      If you are a tty driver author converting an out of tree driver the only
      impact should be termios->ktermios name changes for the speed/property
      setting functions from your upper layers.
      
      If you are implementing your own TCGETS function before then your driver
      was broken already and its about to get a whole lot more painful for you so
      please fix it 8)
      
      Also fill in c_ispeed/ospeed on init for most devices, although the current
      code will do this for you anyway but I'd like eventually to lose that extra
      paranoia
      
      [akpm@osdl.org: bluetooth fix]
      [mp3@de.ibm.com: sclp fix]
      [mp3@de.ibm.com: warning fix for tty3270]
      [hugh@veritas.com: fix tty_ioctl powerpc build]
      [jdike@addtoit.com: uml: fix ->set_termios declaration]
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NMartin Peschke <mp3@de.ibm.com>
      Acked-by: NPeter Oberparleiter <oberpar@de.ibm.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      606d099c
  24. 29 6月, 2006 1 次提交
    • P
      [PATCH] remove TTY_DONT_FLIP · 817d6d3b
      Paul Fulghum 提交于
      Remove TTY_DONT_FLIP tty flag.  This flag was introduced in 2.1.X kernels
      to prevent the N_TTY line discipline functions read_chan() and
      n_tty_receive_buf() from running at the same time.  2.2.15 introduced
      tty->read_lock to protect access to the N_TTY read buffer, which is the
      only state requiring protection between these two functions.
      
      The current TTY_DONT_FLIP implementation is broken for SMP, and is not
      universally honored by drivers that send data directly to the line
      discipline receive_buf function.
      
      Because TTY_DONT_FLIP is not necessary, is broken in implementation, and is
      not universally honored, it is removed.
      Signed-off-by: NPaul Fulghum <paulkf@microgate.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      817d6d3b
  25. 12 6月, 2006 1 次提交
    • P
      [PATCH] Fix for the PPTP hangs that have been reported · 289a1e99
      Paul Mackerras 提交于
      People have been reporting that PPP connections over ptys, such as
      used with PPTP, will hang randomly when transferring large amounts of
      data, for instance in http://bugzilla.kernel.org/show_bug.cgi?id=6530.
      I have managed to reproduce the problem, and the patch below fixes the
      actual cause.
      
      The problem is not in fact in ppp_async.c but in n_tty.c.  What
      happens is that when pptp reads from the pty, we call read_chan() in
      drivers/char/n_tty.c on the master side of the pty.  That copies all
      the characters out of its buffer to userspace and then calls
      check_unthrottle(), which calls the pty unthrottle routine, which
      calls tty_wakeup on the slave side, which calls ppp_asynctty_wakeup,
      which calls tasklet_schedule.  So far so good.  Since we are in
      process context, the tasklet runs immediately and calls
      ppp_async_process(), which calls ppp_async_push, which calls the
      tty->driver->write function to send some more output.
      
      However, tty->driver->write() returns zero, because the master
      tty->receive_room is still zero.  We haven't returned from
      check_unthrottle() yet, and read_chan() only updates tty->receive_room
      _after_ calling check_unthrottle.  That means that the driver->write
      call in ppp_async_process() returns 0.  That would be fine if we were
      going to get a subsequent wakeup call, but we aren't (we just had it,
      and the buffer is now empty).
      
      The solution is for n_tty.c to update tty->receive_room _before_
      calling the driver unthrottle routine.  The patch below does this.
      With this patch I was able to transfer a 900MB file over a PPTP
      connection (taking about 25 minutes), whereas without the patch the
      connection would always stall in under a minute.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      289a1e99