1. 01 10月, 2013 1 次提交
    • P
      tty: Fix pty master read() after slave closes · f8747d4a
      Peter Hurley 提交于
      Commit f95499c3,
        n_tty: Don't wait for buffer work in read() loop
      creates a race window which can cause a pty master read()
      to miss the last pty slave write(s) and return -EIO instead,
      thus signalling the pty slave is closed. This can happen when
      the pty slave is written and immediately closed but before the
      tty buffer i/o loop receives the new input; the pty master
      read() is scheduled, sees its read buffer is empty and the
      pty slave has been closed, and exits.
      
      Because tty_flush_to_ldisc() has significant performance impact
      for parallel i/o, rather than revert the commit, special case this
      condition (ie., when the read buffer is empty and the 'other' pty
      has been closed) and, only then, wait for buffer work to complete
      before re-testing if the read buffer is still empty.
      
      As before, subsequent pty master reads return any available data
      until no more data is available, and then returns -EIO to
      indicate the pty slave has closed.
      Reported-by: NMikael Pettersson <mikpelinux@gmail.com>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Tested-by: NMikael Pettersson <mikpelinux@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8747d4a
  2. 18 9月, 2013 1 次提交
  3. 13 8月, 2013 1 次提交
    • P
      n_tty: Fix termios_rwsem lockdep false positive · aefceaf4
      Peter Hurley 提交于
      Lockdep reports a circular lock dependency between
      atomic_read_lock and termios_rwsem [1]. However, a lock
      order deadlock is not possible since CPU1 only holds a
      read lock which cannot prevent CPU0 from also acquiring
      a read lock on the same r/w semaphore.
      
      Unfortunately, lockdep cannot currently distinguish whether
      the locks are read or write for any particular lock graph,
      merely that the locks _were_ previously read and/or write.
      
      Until lockdep is fixed, re-order atomic_read_lock so
      termios_rwsem can be dropped and reacquired without
      triggering lockdep.
      
      Patch based on original posted here https://lkml.org/lkml/2013/8/1/510
      by Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      
      [1] Initial lockdep report from Artem Savkov <artem.savkov@gmail.com>
      
       ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.11.0-rc3-next-20130730+ #140 Tainted: G        W
       -------------------------------------------------------
       bash/1198 is trying to acquire lock:
        (&tty->termios_rwsem){++++..}, at: [<ffffffff816aa3bb>] n_tty_read+0x49b/0x660
      
       but task is already holding lock:
        (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff816aa0f0>] n_tty_read+0x1d0/0x660
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&ldata->atomic_read_lock){+.+...}:
              [<ffffffff811111cc>] validate_chain+0x73c/0x850
              [<ffffffff811117e0>] __lock_acquire+0x500/0x5d0
              [<ffffffff81111a29>] lock_acquire+0x179/0x1d0
              [<ffffffff81d34b9c>] mutex_lock_interruptible_nested+0x7c/0x540
              [<ffffffff816aa0f0>] n_tty_read+0x1d0/0x660
              [<ffffffff816a3bb6>] tty_read+0x86/0xf0
              [<ffffffff811f21d3>] vfs_read+0xc3/0x130
              [<ffffffff811f2702>] SyS_read+0x62/0xa0
              [<ffffffff81d45259>] system_call_fastpath+0x16/0x1b
      
       -> #0 (&tty->termios_rwsem){++++..}:
              [<ffffffff8111064f>] check_prev_add+0x14f/0x590
              [<ffffffff811111cc>] validate_chain+0x73c/0x850
              [<ffffffff811117e0>] __lock_acquire+0x500/0x5d0
              [<ffffffff81111a29>] lock_acquire+0x179/0x1d0
              [<ffffffff81d372c1>] down_read+0x51/0xa0
              [<ffffffff816aa3bb>] n_tty_read+0x49b/0x660
              [<ffffffff816a3bb6>] tty_read+0x86/0xf0
              [<ffffffff811f21d3>] vfs_read+0xc3/0x130
              [<ffffffff811f2702>] SyS_read+0x62/0xa0
              [<ffffffff81d45259>] system_call_fastpath+0x16/0x1b
      
       other info that might help us debug this:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&ldata->atomic_read_lock);
                                      lock(&tty->termios_rwsem);
                                      lock(&ldata->atomic_read_lock);
         lock(&tty->termios_rwsem);
      
        *** DEADLOCK ***
      
       2 locks held by bash/1198:
        #0:  (&tty->ldisc_sem){.+.+.+}, at: [<ffffffff816ade04>] tty_ldisc_ref_wait+0x24/0x60
        #1:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff816aa0f0>] n_tty_read+0x1d0/0x660
      
       stack backtrace:
       CPU: 1 PID: 1198 Comm: bash Tainted: G        W    3.11.0-rc3-next-20130730+ #140
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
        0000000000000000 ffff880019acdb28 ffffffff81d34074 0000000000000002
        0000000000000000 ffff880019acdb78 ffffffff8110ed75 ffff880019acdb98
        ffff880019fd0000 ffff880019acdb78 ffff880019fd0638 ffff880019fd0670
       Call Trace:
        [<ffffffff81d34074>] dump_stack+0x59/0x7d
        [<ffffffff8110ed75>] print_circular_bug+0x105/0x120
        [<ffffffff8111064f>] check_prev_add+0x14f/0x590
        [<ffffffff81d3ab5f>] ? _raw_spin_unlock_irq+0x4f/0x70
        [<ffffffff811111cc>] validate_chain+0x73c/0x850
        [<ffffffff8110ae0f>] ? trace_hardirqs_off_caller+0x1f/0x190
        [<ffffffff811117e0>] __lock_acquire+0x500/0x5d0
        [<ffffffff81111a29>] lock_acquire+0x179/0x1d0
        [<ffffffff816aa3bb>] ? n_tty_read+0x49b/0x660
        [<ffffffff81d372c1>] down_read+0x51/0xa0
        [<ffffffff816aa3bb>] ? n_tty_read+0x49b/0x660
        [<ffffffff816aa3bb>] n_tty_read+0x49b/0x660
        [<ffffffff810e4130>] ? try_to_wake_up+0x210/0x210
        [<ffffffff816a3bb6>] tty_read+0x86/0xf0
        [<ffffffff811f21d3>] vfs_read+0xc3/0x130
        [<ffffffff811f2702>] SyS_read+0x62/0xa0
        [<ffffffff815e24ee>] ? trace_hardirqs_on_thunk+0x3a/0x3f
        [<ffffffff81d45259>] system_call_fastpath+0x16/0x1b
      Reported-by: NArtem Savkov <artem.savkov@gmail.com>
      Reported-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aefceaf4
  4. 25 7月, 2013 9 次提交
  5. 24 7月, 2013 28 次提交