1. 05 10月, 2015 2 次提交
  2. 24 7月, 2015 2 次提交
  3. 11 5月, 2015 2 次提交
    • P
      pty: Fix input race when closing · 1a48632f
      Peter Hurley 提交于
      A read() from a pty master may mistakenly indicate EOF (errno == -EIO)
      after the pty slave has closed, even though input data remains to be read.
      For example,
      
             pty slave       |        input worker        |    pty master
                             |                            |
                             |                            |   n_tty_read()
      pty_write()            |                            |     input avail? no
        add data             |                            |     sleep
        schedule worker  --->|                            |     .
                             |---> flush_to_ldisc()       |     .
      pty_close()            |       fill read buffer     |     .
        wait for worker      |       wakeup reader    --->|     .
                             |       read buffer full?    |---> input avail ? yes
                             |<---   yes - exit worker    |     copy 4096 bytes to user
        TTY_OTHER_CLOSED <---|                            |<--- kick worker
                             |                            |
      
      		                **** New read() before worker starts ****
      
                             |                            |   n_tty_read()
                             |                            |     input avail? no
                             |                            |     TTY_OTHER_CLOSED? yes
                             |                            |     return -EIO
      
      Several conditions are required to trigger this race:
      1. the ldisc read buffer must become full so the input worker exits
      2. the read() count parameter must be >= 4096 so the ldisc read buffer
         is empty
      3. the subsequent read() occurs before the kicked worker has processed
         more input
      
      However, the underlying cause of the race is that data is pipelined, while
      tty state is not; ie., data already written by the pty slave end is not
      yet visible to the pty master end, but state changes by the pty slave end
      are visible to the pty master end immediately.
      
      Pipeline the TTY_OTHER_CLOSED state through input worker to the reader.
      1. Introduce TTY_OTHER_DONE which is set by the input worker when
         TTY_OTHER_CLOSED is set and either the input buffers are flushed or
         input processing has completed. Readers/polls are woken when
         TTY_OTHER_DONE is set.
      2. Reader/poll checks TTY_OTHER_DONE instead of TTY_OTHER_CLOSED.
      3. A new input worker is started from pty_close() after setting
         TTY_OTHER_CLOSED, which ensures the TTY_OTHER_DONE state will be
         set if the last input worker is already finished (or just about to
         exit).
      
      Remove tty_flush_to_ldisc(); no in-tree callers.
      
      Fixes: 52bce7f8 ("pty, n_tty: Simplify input processing on final close")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96311
      BugLink: http://bugs.launchpad.net/bugs/1429756
      Cc: <stable@vger.kernel.org> # 3.19+
      Reported-by: NAndy Whitcroft <apw@canonical.com>
      Reported-by: NH.J. Lu <hjl.tools@gmail.com>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1a48632f
    • G
      tty: tty_buffer.c: move assignment out of if () block · e16cb0a7
      Greg Kroah-Hartman 提交于
      We should not be doing assignments within an if () block
      so fix up the code to not do this.
      
      change was created using Coccinelle.
      
      CC: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e16cb0a7
  4. 03 2月, 2015 1 次提交
    • P
      pty: Fix buffer flush deadlock · 1d1d14da
      Peter Hurley 提交于
      The pty driver does not clear its write buffer when commanded.
      This is to avoid an apparent deadlock between parallel flushes from
      both pty ends; specifically when handling either BRK or INTR input.
      However, parallel flushes from this source is not possible since
      the pty master can never be set to BRKINT or ISIG. Parallel flushes
      from other sources are possible but these do not threaten deadlocks.
      
      Annotate the tty buffer mutex for lockdep to represent the nested
      tty_buffer locking which occurs when the pty slave is processing input
      (its buffer mutex held) and receives INTR or BRK and acquires the
      linked tty buffer mutex via tty_buffer_flush().
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d1d14da
  5. 06 11月, 2014 1 次提交
    • P
      tty: Flush ldisc buffer atomically with tty flip buffers · 86c80a8e
      Peter Hurley 提交于
      tty_ldisc_flush() first clears the line discipline input buffer,
      then clears the tty flip buffers. However, this allows for existing
      data in the tty flip buffers to be added after the ldisc input
      buffer has been cleared, but before the flip buffers have been cleared.
      
      Add an optional ldisc parameter to tty_buffer_flush() to allow
      tty_ldisc_flush() to pass the ldisc to clear.
      
      NB: Initially, the plan was to do this automatically in
      tty_buffer_flush(). However, an audit of the behavior of existing
      line disciplines showed that performing a ldisc buffer flush on
      ioctl(TCFLSH) was not always the outcome. For example, some line
      disciplines have flush_buffer() methods but not ioctl() methods,
      so a ->flush_buffer() command would be unexpected.
      Reviewed-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86c80a8e
  6. 24 5月, 2014 1 次提交
  7. 04 5月, 2014 2 次提交
  8. 25 4月, 2014 1 次提交
    • M
      tty: Fix race condition between __tty_buffer_request_room and flush_to_ldisc · 6a20dbd6
      Manfred Schlaegl 提交于
      The race was introduced while development of linux-3.11 by
      e8437d7e and
      e9975fde.
      Originally it was found and reproduced on linux-3.12.15 and
      linux-3.12.15-rt25, by sending 500 byte blocks with 115kbaud to the
      target uart in a loop with 100 milliseconds delay.
      
      In short:
       1. The consumer flush_to_ldisc is on to remove the head tty_buffer.
       2. The producer adds a number of bytes, so that a new tty_buffer must
      	be allocated and added by __tty_buffer_request_room.
       3. The consumer removes the head tty_buffer element, without handling
      	newly committed data.
      
      Detailed example:
       * Initial buffer:
         * Head, Tail -> 0: used=250; commit=250; read=240; next=NULL
       * Consumer: ''flush_to_ldisc''
         * consumed 10 Byte
         * buffer:
           * Head, Tail -> 0: used=250; commit=250; read=250; next=NULL
      {{{
      		count = head->commit - head->read;	// count = 0
      		if (!count) {				// enter
      			// INTERRUPTED BY PRODUCER ->
      			if (head->next == NULL)
      				break;
      			buf->head = head->next;
      			tty_buffer_free(port, head);
      			continue;
      		}
      }}}
       * Producer: tty_insert_flip_... 10 bytes + tty_flip_buffer_push
         * buffer:
           * Head, Tail -> 0: used=250; commit=250; read=250; next=NULL
         * added 6 bytes: head-element filled to maximum.
           * buffer:
             * Head, Tail -> 0: used=256; commit=250; read=250; next=NULL
         * added 4 bytes: __tty_buffer_request_room is called
           * buffer:
             * Head -> 0: used=256; commit=256; read=250; next=1
             * Tail -> 1: used=4; commit=0; read=250 next=NULL
         * push (tty_flip_buffer_push)
           * buffer:
             * Head -> 0: used=256; commit=256; read=250; next=1
             * Tail -> 1: used=4; commit=4; read=250 next=NULL
       * Consumer
      {{{
      		count = head->commit - head->read;
      		if (!count) {
      			// INTERRUPTED BY PRODUCER <-
      			if (head->next == NULL)		// -> no break
      				break;
      			buf->head = head->next;
      			tty_buffer_free(port, head);
      			// ERROR: tty_buffer head freed -> 6 bytes lost
      			continue;
      		}
      }}}
      
      This patch reintroduces a spin_lock to protect this case. Perhaps later
      a lock-less solution could be found.
      Signed-off-by: NManfred Schlaegl <manfred.schlaegl@gmx.at>
      Cc: stable <stable@vger.kernel.org> # 3.11
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a20dbd6
  9. 01 3月, 2014 1 次提交
    • P
      tty: Fix low_latency BUG · a9c3f68f
      Peter Hurley 提交于
      The user-settable knob, low_latency, has been the source of
      several BUG reports which stem from flush_to_ldisc() running
      in interrupt context. Since 3.12, which added several sleeping
      locks (termios_rwsem and buf->lock) to the input processing path,
      the frequency of these BUG reports has increased.
      
      Note that changes in 3.12 did not introduce this regression;
      sleeping locks were first added to the input processing path
      with the removal of the BKL from N_TTY in commit
      a88a69c9,
      'n_tty: Fix loss of echoed characters and remove bkl from n_tty'
      and later in commit 38db8979,
      'tty: throttling race fix'. Since those changes, executing
      flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe.
      
      However, since most devices do not validate if the low_latency
      setting is appropriate for the context (process or interrupt) in
      which they receive data, some reports are due to misconfiguration.
      Further, serial dma devices for which dma fails, resort to
      interrupt receiving as a backup without resetting low_latency.
      
      Historically, low_latency was used to force wake-up the reading
      process rather than wait for the next scheduler tick. The
      effect was to trim multiple milliseconds of latency from
      when the process would receive new data.
      
      Recent tests [1] have shown that the reading process now receives
      data with only 10's of microseconds latency without low_latency set.
      
      Remove the low_latency rx steering from tty_flip_buffer_push();
      however, leave the knob as an optional hint to drivers that can
      tune their rx fifos and such like. Cleanup stale code comments
      regarding low_latency.
      
      [1] https://lkml.org/lkml/2014/2/20/434
      
      "Yay.. thats an annoying historical pain in the butt gone."
      	-- Alan Cox
      Reported-by: NBeat Bolli <bbolli@ewanet.ch>
      Reported-by: NPavel Roskin <proski@gnu.org>
      Acked-by: NDavid Sterba <dsterba@suse.cz>
      Cc: Grant Edwards <grant.b.edwards@gmail.com>
      Cc: Stanislaw Gruszka <sgruszka@redhat.com>
      Cc: Hal Murray <murray+fedora@ip-64-139-1-69.sjc.megapath.net>
      Cc: <stable@vger.kernel.org> # 3.12.x+
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a9c3f68f
  10. 08 1月, 2014 1 次提交
  11. 10 12月, 2013 1 次提交
  12. 09 12月, 2013 5 次提交
  13. 24 7月, 2013 18 次提交
  14. 10 4月, 2013 1 次提交
    • P
      tty: Fix race condition if flushing tty flip buffers · 39f610e4
      Peter Hurley 提交于
      As Ilya Zykov identified in his patch 'PROBLEM: Race condition in
      tty buffer's function flush_to_ldisc()', a race condition exists
      which allows a parallel flush_to_ldisc() to flush and free the tty
      flip buffers while those buffers are in-use. For example,
      
        CPU 0                         |  CPU 1                                  |  CPU 2
                                      | flush_to_ldisc()                        |
                                      |  grab spin lock                         |
      tty_buffer_flush()              |                                         | flush_to_ldisc()
       wait for spin lock             |                                         |  wait for spin lock
                                      |   if (!test_and_set_bit(TTYP_FLUSHING)) |
                                      |    while (next flip buffer)             |
                                      |     ...                                 |
                                      |     drop spin lock                      |
        grab spin lock                |                                         |
         if (test_bit(TTYP_FLUSHING)) |                                         |
          set_bit(TTYP_FLUSHPENDING)  |      receive_buf()                      |
          drop spin lock              |                                         |
                                      |                                         |   grab spin lock
                                      |                                         |    if (!test_and_set_bit(TTYP_FLUSHING))
                                      |                                         |    if (test_bit(TTYP_FLUSHPENDING))
                                      |                                         |    __tty_buffer_flush()
      
      CPU 2 has just flushed and freed all tty flip buffers while CPU 1 is
      transferring data from the head flip buffer.
      
      The original patch was rejected under the assumption that parallel
      flush_to_ldisc() was not possible. Because of necessary changes to
      the workqueue api, work items can execute in parallel on SMP.
      
      This patch differs slightly from the original patch by testing for
      a pending flush _after_ each receive_buf(), since TTYP_FLUSHPENDING
      can only be set while the lock is dropped around receive_buf().
      Reported-by: NIlya Zykov <linux@izyk.ru>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Acked-by: NIlya Zykov <linux@izyk.ru>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39f610e4
  15. 04 3月, 2013 1 次提交