1. 09 12月, 2013 3 次提交
  2. 24 7月, 2013 18 次提交
  3. 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
  4. 04 3月, 2013 1 次提交
  5. 14 2月, 2013 1 次提交
    • G
      pps: Move timestamp read into PPS code proper · 593fb1ae
      George Spelvin 提交于
      The PPS (Pulse-Per-Second) line discipline has developed a number of
      unhealthy attachments to core tty data and functions, ultimately leading
      to its breakage.
      
      The previous patches fixed the crashing.  This one reduces coupling further
      by eliminating the timestamp parameter from the dcd_change ldisc method.
      This reduces header file linkage and makes the extension more generic,
      and the timestamp read is delayed only slightly, from just before the
      ldisc->ops->dcd_change method call to just after.
      
      Fix attendant build breakage in
          drivers/tty/n_tty.c
          drivers/tty/tty_buffer.c
          drivers/staging/speakup/selection.c
          drivers/staging/dgrp/dgrp_*.c
      
      Cc: William Hubbs <w.d.hubbs@gmail.com>
      Cc: Chris Brannon <chris@the-brannons.com>
      Cc: Kirk Reiser <kirk@braille.uwo.ca>
      Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGeorge Spelvin <linux@horizon.com>
      Acked-by: NRodolfo Giometti <giometti@enneenne.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      593fb1ae
  6. 21 1月, 2013 1 次提交
    • I
      tty: Correct tty buffer flush. · 64325a3b
      Ilya Zykov 提交于
        The root of problem is carelessly zeroing pointer(in function __tty_buffer_flush()),
      when another thread can use it. It can be cause of "NULL pointer dereference".
        Main idea of the patch, this is never free last (struct tty_buffer) in the active buffer.
      Only flush the data for ldisc(buf->head->read = buf->head->commit).
      At that moment driver can collect(write) data in buffer without conflict.
      It is repeat behavior of flush_to_ldisc(), only without feeding data to ldisc.
      
      Also revert:
        commit c56a00a1
        tty: hold lock across tty buffer finding and buffer filling
      In order to delete the unneeded locks any more.
      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>
      64325a3b
  7. 16 1月, 2013 5 次提交
  8. 26 10月, 2012 1 次提交
  9. 25 10月, 2012 1 次提交
  10. 23 10月, 2012 4 次提交
  11. 10 4月, 2012 1 次提交
  12. 08 6月, 2011 1 次提交
    • L
      tty_buffer: get rid of 'seen_tail' logic in flush_to_ldisc · 81de916f
      Linus Torvalds 提交于
      The flush_to_ldisc() work entry has special logic to notice when it has
      seen the original tail of the data queue, and it avoids continuing the
      flush if it sees that _original_ tail rather than the current tail.
      
      This logic can trigger in case somebody is constantly adding new data to
      the tty while the flushing is active - and the intent is to avoid
      excessive CPU usage while flushing the tty, especially as we used to do
      this from a softirq context which made it non-preemptible.
      
      However, since we no longer re-arm the work-queue from within itself
      (because that causes other trouble: see commit a5660b41 "tty: fix
      endless work loop when the buffer fills up"), this just leads to
      possible hung tty's (most easily seen in SMP and with a test-program
      that floods a pty with data - nobody seems to have reported this for any
      real-life situation yet).
      
      And since the workqueue isn't done from timers and softirq's any more,
      it's doubtful whether the CPU useage issue is really relevant any more.
      So just remove the logic entirely, and see if anybody ever notices.
      
      Alternatively, we might want to re-introduce the "re-arm the work" for
      just this case, but then we'd have to re-introduce the delayed work
      model or some explicit timer, which really doesn't seem worth it for
      this.
      Reported-and-tested-by: NGuillaume Chazarain <guichaz@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      81de916f
  13. 04 6月, 2011 1 次提交
    • L
      Revert "tty: make receive_buf() return the amout of bytes received" · 55db4c64
      Linus Torvalds 提交于
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Reported-by: NMilton 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: NLinus Torvalds <torvalds@linux-foundation.org>
      55db4c64
  14. 23 4月, 2011 1 次提交