1. 19 3月, 2013 11 次提交
  2. 16 1月, 2013 2 次提交
    • S
      tty: don't deadlock while flushing workqueue · 852e4a81
      Sebastian Andrzej Siewior 提交于
      Since commit 89c8d91e ("tty: localise the lock") I see a dead lock
      in one of my dummy_hcd + g_nokia test cases. The first run was usually
      okay, the second often resulted in a splat by lockdep and the third was
      usually a dead lock.
      Lockdep complained about tty->hangup_work and tty->legacy_mutex taken
      both ways:
      | ======================================================
      | [ INFO: possible circular locking dependency detected ]
      | 3.7.0-rc6+ #204 Not tainted
      | -------------------------------------------------------
      | kworker/2:1/35 is trying to acquire lock:
      |  (&tty->legacy_mutex){+.+.+.}, at: [<c14051e6>] tty_lock_nested+0x36/0x80
      |
      | but task is already holding lock:
      |  ((&tty->hangup_work)){+.+...}, at: [<c104f6e4>] process_one_work+0x124/0x5e0
      |
      | which lock already depends on the new lock.
      |
      | the existing dependency chain (in reverse order) is:
      |
      | -> #2 ((&tty->hangup_work)){+.+...}:
      |        [<c107fe74>] lock_acquire+0x84/0x190
      |        [<c104d82d>] flush_work+0x3d/0x240
      |        [<c12e6986>] tty_ldisc_flush_works+0x16/0x30
      |        [<c12e7861>] tty_ldisc_release+0x21/0x70
      |        [<c12e0dfc>] tty_release+0x35c/0x470
      |        [<c1105e28>] __fput+0xd8/0x270
      |        [<c1105fcd>] ____fput+0xd/0x10
      |        [<c1051dd9>] task_work_run+0xb9/0xf0
      |        [<c1002a51>] do_notify_resume+0x51/0x80
      |        [<c140550a>] work_notifysig+0x35/0x3b
      |
      | -> #1 (&tty->legacy_mutex/1){+.+...}:
      |        [<c107fe74>] lock_acquire+0x84/0x190
      |        [<c140276c>] mutex_lock_nested+0x6c/0x2f0
      |        [<c14051e6>] tty_lock_nested+0x36/0x80
      |        [<c1405279>] tty_lock_pair+0x29/0x70
      |        [<c12e0bb8>] tty_release+0x118/0x470
      |        [<c1105e28>] __fput+0xd8/0x270
      |        [<c1105fcd>] ____fput+0xd/0x10
      |        [<c1051dd9>] task_work_run+0xb9/0xf0
      |        [<c1002a51>] do_notify_resume+0x51/0x80
      |        [<c140550a>] work_notifysig+0x35/0x3b
      |
      | -> #0 (&tty->legacy_mutex){+.+.+.}:
      |        [<c107f3c9>] __lock_acquire+0x1189/0x16a0
      |        [<c107fe74>] lock_acquire+0x84/0x190
      |        [<c140276c>] mutex_lock_nested+0x6c/0x2f0
      |        [<c14051e6>] tty_lock_nested+0x36/0x80
      |        [<c140523f>] tty_lock+0xf/0x20
      |        [<c12df8e4>] __tty_hangup+0x54/0x410
      |        [<c12dfcb2>] do_tty_hangup+0x12/0x20
      |        [<c104f763>] process_one_work+0x1a3/0x5e0
      |        [<c104fec9>] worker_thread+0x119/0x3a0
      |        [<c1055084>] kthread+0x94/0xa0
      |        [<c140ca37>] ret_from_kernel_thread+0x1b/0x28
      |
      |other info that might help us debug this:
      |
      |Chain exists of:
      |  &tty->legacy_mutex --> &tty->legacy_mutex/1 --> (&tty->hangup_work)
      |
      | Possible unsafe locking scenario:
      |
      |       CPU0                    CPU1
      |       ----                    ----
      |  lock((&tty->hangup_work));
      |                               lock(&tty->legacy_mutex/1);
      |                               lock((&tty->hangup_work));
      |  lock(&tty->legacy_mutex);
      |
      | *** DEADLOCK ***
      
      Before the path mentioned tty_ldisc_release() look like this:
      
      |	tty_ldisc_halt(tty);
      |	tty_ldisc_flush_works(tty);
      |	tty_lock();
      
      As it can be seen, it first flushes the workqueue and then grabs the
      tty_lock. Now we grab the lock first:
      
      |	tty_lock_pair(tty, o_tty);
      |	tty_ldisc_halt(tty);
      |	tty_ldisc_flush_works(tty);
      
      so lockdep's complaint seems valid.
      
      The earlier version of this patch took the ldisc_mutex since the other
      user of tty_ldisc_flush_works() (tty_set_ldisc()) did this.
      Peter Hurley then said that it is should not be requried. Since it
      wasn't done earlier, I dropped this part.
      The code under tty_ldisc_kill() was executed earlier with the tty lock
      taken so it is taken again.
      
      I was able to reproduce the deadlock on v3.8-rc1, this patch fixes the
      problem in my testcase. I didn't notice any problems so far.
      
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      852e4a81
    • I
      tty: Only wakeup the line discipline idle queue when queue is active · bd5d7ce9
      Ivo Sieben 提交于
      Before waking up the tty line discipline idle queue first check if the queue is
      active (non empty). This prevents unnecessary entering the critical section in
      the wake_up() function and therefore avoid needless scheduling overhead on a
      PREEMPT_RT system caused by two processes being in the same critical section.
      Signed-off-by: NIvo Sieben <meltedpianoman@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bd5d7ce9
  3. 25 10月, 2012 1 次提交
  4. 23 10月, 2012 2 次提交
    • J
      TTY: move tty buffers to tty_port · ecbbfd44
      Jiri Slaby 提交于
      So this is it. The big step why we did all the work over the past
      kernel releases. Now everything is prepared, so nothing protects us
      from doing that big step.
      
                 |  |            \  \ nnnn/^l      |  |
                 |  |             \  /     /       |  |
                 |  '-,.__   =>    \/   ,-`    =>  |  '-,.__
                 | O __.´´)        (  .`           | O __.´´)
                  ~~~   ~~          ``              ~~~   ~~
      The buffers are now in the tty_port structure and we can start
      teaching the buffer helpers (insert char/string, flip etc.) to use
      tty_port instead of tty_struct all around.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ecbbfd44
    • J
      TTY: ldisc, wait for idle ldisc in release · 31e12128
      Jiri Slaby 提交于
      We reintroduced tty_ldisc_wait_idle in 100eeae2 (TTY: restore
      tty_ldisc_wait_idle) and used in set_ldisc. Then we added it also to
      the hangup path in 92f6fa09 (TTY: ldisc, do not close until there
      are readers). And we noted that there is one more path:
      ~   Before 65b77046 tty_ldisc_wait_idle was called also from
      ~   tty_ldisc_release. It is called from tty_release, so I don't think
      ~   we need to restore that one.
      
      Well, I was wrong. There might still be holders of an ldisc
      reference. Not from userspace, but drivers. If they take a reference
      and a user closes the device immediately after that, we have a
      problem. ldisc is halted and closed by TTY, but the driver still may
      call some ldisc's operation and cause a crash.
      
      So restore the tty_ldisc_wait_idle call also to the third location
      where it was before 65b77046 (tty-ldisc: turn ldisc user count
      into a proper refcount). Now we should be safe with respect to the
      ldisc reference counting as all* tty_ldisc_close paths are safely
      called with reference count of one.
      
      * Not the one in tty_ldisc_setup's fail path. But that is called
        before the first open finishes. So userspace does not see it yet.
        Even thought the driver is given the TTY already via ->install, it
        should not take a reference to the ldisc yet. If some driver is to
        do this, we should put one tty_ldisc_wait_idle also in the setup.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31e12128
  5. 21 8月, 2012 1 次提交
    • T
      workqueue: deprecate flush[_delayed]_work_sync() · 43829731
      Tejun Heo 提交于
      flush[_delayed]_work_sync() are now spurious.  Mark them deprecated
      and convert all users to flush[_delayed]_work().
      
      If you're cc'd and wondering what's going on: Now all workqueues are
      non-reentrant and the regular flushes guarantee that the work item is
      not pending or running on any CPU on return, so there's no reason to
      use the sync flushes at all and they're going away.
      
      This patch doesn't make any functional difference.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Mattia Dongili <malattia@linux.it>
      Cc: Kent Yoder <key@linux.vnet.ibm.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: Bryan Wu <bryan.wu@canonical.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Alasdair Kergon <agk@redhat.com>
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-wireless@vger.kernel.org
      Cc: Anton Vorontsov <cbou@mail.ru>
      Cc: Sangbeom Kim <sbkim73@samsung.com>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Petr Vandrovec <petr@vandrovec.name>
      Cc: Mark Fasheh <mfasheh@suse.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Avi Kivity <avi@redhat.com> 
      43829731
  6. 11 8月, 2012 1 次提交
    • A
      tty: localise the lock · 89c8d91e
      Alan Cox 提交于
      The termios and other changes mean the other protections needed on the driver
      tty arrays should be adequate. Turn it all back on.
      
      This contains pieces folded in from the fixes made to the original patches
      
      | From: Geert Uytterhoeven <geert@linux-m68k.org>	(fix m68k)
      | From: Paul Gortmaker <paul.gortmaker@windriver.com>	(fix cris)
      | From: Jiri Kosina <jkosina@suze.cz>			(lockdep)
      | From: Eric Dumazet <eric.dumazet@gmail.com>		(lockdep)
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89c8d91e
  7. 28 7月, 2012 1 次提交
    • A
      tty: Fix race in tty release · d155255a
      Alan Cox 提交于
      Ian Abbott found that the tty layer would explode with the right set of
      parallel open and close operations. This is because we race in the
      handling of tty->drivers->termios[].
      
      Correct this by
      	Making tty_ldisc_release behave like nromal code (takes the lock,
      			does stuff, drops the lock)
      	Drop the tty lock earlier in tty_ldisc_release
      	Taking the tty mutex around the driver->termios update in all cases
      	Adding a WARN_ON to catch future screwups.
      
      I also forgot to clean up the pty resources properly. With a pty pair we
      need to pull both halves out of the tables.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Tested-by: NIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d155255a
  8. 27 7月, 2012 1 次提交
  9. 17 7月, 2012 2 次提交
  10. 13 7月, 2012 1 次提交
  11. 07 7月, 2012 1 次提交
    • A
      tty: localise the lock · f5e3bcc5
      Alan Cox 提交于
      The termios and other changes mean the other protections needed on the driver
      tty arrays should be adequate. Turn it all back on.
      
      This contains pieces folded in from the fixes made to the original patches
      
      | From: Geert Uytterhoeven <geert@linux-m68k.org>	(fix m68k)
      | From: Paul Gortmaker <paul.gortmaker@windriver.com>	(fix cris)
      | From: Jiri Kosina <jkosina@suze.cz>			(lockdep)
      | From: Eric Dumazet <eric.dumazet@gmail.com>		(lockdep)
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5e3bcc5
  12. 03 6月, 2012 1 次提交
    • L
      tty: Revert the tty locking series, it needs more work · f309532b
      Linus Torvalds 提交于
      This reverts the tty layer change to use per-tty locking, because it's
      not correct yet, and fixing it will require some more deep surgery.
      
      The main revert is d29f3ef3 ("tty_lock: Localise the lock"), but
      there are several smaller commits that built upon it, they also get
      reverted here. The list of reverted commits is:
      
        fde86d31 - tty: add lockdep annotations
        8f6576ad - tty: fix ldisc lock inversion trace
        d3ca8b64 - pty: Fix lock inversion
        b1d679af - tty: drop the pty lock during hangup
        abcefe5f - tty/amiserial: Add missing argument for tty_unlock()
        fd11b42e - cris: fix missing tty arg in wait_event_interruptible_tty call
        d29f3ef3 - tty_lock: Localise the lock
      
      The revert had a trivial conflict in the 68360serial.c staging driver
      that got removed in the meantime.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f309532b
  13. 30 5月, 2012 1 次提交
  14. 11 5月, 2012 1 次提交
  15. 05 5月, 2012 1 次提交
  16. 18 11月, 2011 4 次提交
    • J
      TTY: ldisc, remove some unneeded includes · 8b3ffa17
      Jiri Slaby 提交于
      They were cut&pasted from tty_io. Many of them are not needed in
      tty_ldisc.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Alan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8b3ffa17
    • J
      TTY: ldisc, wait for ldisc infinitely in hangup · 0c73c08e
      Jiri Slaby 提交于
      For /dev/console case, we do not kill all ldisc users. It's due to
      redirected_tty_write test in __tty_hangup. In that case there still
      might be a process waiting e.g. in n_tty_read for input.
      
      We wait for such processes to disappear. The problem is that we use a
      timeout. After this timeout, we continue closing the ldisc and start
      freeing tty resources. It obviously leads to crashes when the other
      process is woken.
      
      So to fix this, we wait infinitely before reiniting the ldisc. (The
      tiocsetd remains untouched -- times out after 5s.)
      
      This is nicely reproducible with this run from shell:
        exec 0<>/dev/console 1<>/dev/console 2<>/dev/console
      and stopping a getty like:
        systemctl stop serial-getty@ttyS0.service
      
      The crash proper may be produced only under load or with constified
      timing the same as for 92f6fa09.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Dave Young <hidave.darkstar@gmail.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Dmitriy Matrosov <sgf.dma@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0c73c08e
    • J
      TTY: ldisc, move wait idle to caller · 30042072
      Jiri Slaby 提交于
      It is the only place where reinit is called from. And we really need
      to wait for the old ldisc to go once. Actually this is the place where
      the waiting originally was (before removed and re-added later).
      
      This will make the fix in the following patch easier to implement.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Dave Young <hidave.darkstar@gmail.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Dmitriy Matrosov <sgf.dma@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      30042072
    • J
      TTY: ldisc, allow waiting for ldisc arbitrarily long · df92d056
      Jiri Slaby 提交于
      To fix a nasty bug in ldisc hup vs. reinit we need to wait infinitely
      long for ldisc to be gone. So here we add a parameter to
      tty_ldisc_wait_idle to allow that.
      
      This is only a preparation for the real fix which is done in the
      following patches.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Dave Young <hidave.darkstar@gmail.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Dmitriy Matrosov <sgf.dma@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      df92d056
  17. 16 11月, 2011 1 次提交
  18. 24 8月, 2011 1 次提交
  19. 08 6月, 2011 1 次提交
    • J
      TTY: ldisc, do not close until there are readers · 92f6fa09
      Jiri Slaby 提交于
      We restored tty_ldisc_wait_idle in 100eeae2 (TTY: restore
      tty_ldisc_wait_idle). We used it in the ldisc changing path to fix the
      case where there are tasks in n_tty_read waiting for data and somebody
      tries to change ldisc.
      
      Similar to the case above, there may be also tasks waiting in
      n_tty_read while hangup is performed. As 65b77046 (tty-ldisc: turn
      ldisc user count into a proper refcount) removed the wait-until-idle
      from all paths, hangup path won't wait for them to disappear either
      now. So add it back even to the hangup path.
      
      There is a difference, we need uninterruptible sleep as there is
      obviously HUP signal pending. So tty_ldisc_wait_idle now sleeps
      without possibility to be interrupted. This is what original
      tty_ldisc_wait_idle did. After the wait idle reintroduction
      (100eeae2), we have had interruptible sleeps for the ldisc changing
      path. But as there is a 5s timeout anyway, we don't allow it to be
      interrupted from now on. It's not worth the added complexity of
      deciding what kind of sleep we want.
      
      Before 65b77046 tty_ldisc_release was called also from
      tty_ldisc_release. It is called from tty_release, so I don't think we
      need to restore that one.
      
      This is nicely reproducible after constifying the timing when
      drivers/tty/n_tty.c is patched as follows ("TTY: ntty, add one more
      sanity check" patch is needed to actually see it explode):
      %% -1548,6 +1549,7 @@ static int n_tty_open(struct tty_struct *tty)
      
              /* These are ugly. Currently a malloc failure here can panic */
              if (!tty->read_buf) {
      +               msleep(100);
                      tty->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL);
                      if (!tty->read_buf)
                              return -ENOMEM;
      %% -1785,6 +1788,7 @@ do_it_again:
                                      break;
                              }
                              timeout = schedule_timeout(timeout);
      +                       msleep(20);
                              continue;
                      }
                      __set_current_state(TASK_RUNNING);
      ===== With a process: =====
          while (1) {
              int fd = open(argv[1], O_RDWR);
              read(fd, buf, sizeof(buf));
              close(fd);
          }
      ===== and its child: =====
              setsid();
              while (1) {
                      int fd = open(tty, O_RDWR|O_NOCTTY);
                      ioctl(fd, TIOCSCTTY, 1);
                      vhangup();
                      close(fd);
                      usleep(100 * (10 + random() % 1000));
              }
      ===== EOF =====
      
      References: https://bugzilla.novell.com/show_bug.cgi?id=693374
      References: https://bugzilla.novell.com/show_bug.cgi?id=694509Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: stable <stable@kernel.org> [32, 33, 34, 39]
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      92f6fa09
  20. 20 4月, 2011 1 次提交
  21. 23 3月, 2011 1 次提交
    • L
      tty: stop using "delayed_work" in the tty layer · f23eb2b2
      Linus Torvalds 提交于
      Using delayed-work for tty flip buffers ends up causing us to wait for
      the next tick to complete some actions.  That's usually not all that
      noticeable, but for certain latency-critical workloads it ends up being
      totally unacceptable.
      
      As an extreme case of this, passing a token back-and-forth over a pty
      will take two ticks per iteration, so even just a thousand iterations
      will take 8 seconds assuming a common 250Hz configuration.
      
      Avoiding the whole delayed work issue brings that ping-pong test-case
      down to 0.009s on my machine.
      
      In more practical terms, this latency has been a performance problem for
      things like dive computer simulators (simulating the serial interface
      using the ptys) and for other environments (Alan mentions a CP/M emulator).
      Reported-by: NJef Driesen <jefdriesen@telenet.be>
      Acked-by: NGreg KH <gregkh@suse.de>
      Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f23eb2b2
  22. 02 3月, 2011 1 次提交
  23. 04 2月, 2011 1 次提交
  24. 30 11月, 2010 1 次提交
    • J
      TTY: ldisc, fix open flag handling · 7f90cfc5
      Jiri Slaby 提交于
      When a concrete ldisc open fails in tty_ldisc_open, we forget to clear
      TTY_LDISC_OPEN. This causes a false warning on the next ldisc open:
      WARNING: at drivers/char/tty_ldisc.c:445 tty_ldisc_open+0x26/0x38()
      Hardware name: System Product Name
      Modules linked in: ...
      Pid: 5251, comm: a.out Tainted: G        W  2.6.32-5-686 #1
      Call Trace:
       [<c1030321>] ? warn_slowpath_common+0x5e/0x8a
       [<c1030357>] ? warn_slowpath_null+0xa/0xc
       [<c119311c>] ? tty_ldisc_open+0x26/0x38
       [<c11936c5>] ? tty_set_ldisc+0x218/0x304
      ...
      
      So clear the bit when failing...
      
      Introduced in c65c9bc3 (tty: rewrite the ldisc locking) back in
      2.6.31-rc1.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Alan Cox <alan@linux.intel.com>
      Reported-by: NSergey Lapin <slapin@ossfans.org>
      Tested-by: NSergey Lapin <slapin@ossfans.org>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7f90cfc5