title: Kernel hanging the tty subsystem
body: <p>I am having some issues with the tty subsystem on a RHEL machine. From what I see in the logs, some kernel oopses are generated each time a new console (be it pts or tty) is spawned. To me it seems that there is some kind of race conditions which occurs there. Here is the stack trace:</p>
  
  <pre><code>kernel:  INFO: task sshd:6338 blocked for more than 120 seconds.
  kernel:       Tainted: P           ---------------    2.6.32-504.el6.x86_64 #1
  kernel:  "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
  kernel:  sshd          D 0000000000000000     0  6338   6195 0x00000080
  kernel:  ffff88035be8d728 0000000000000082 0000000000000000 0000000000000000
  kernel:  ffff88035be8d7f8 ffffffff8105ca34 00009488ef033e83 ffff88035be8d708
  kernel:  ffff88035be8d880 0000000109b91c98 ffff881eea341098 ffff88035be8dfd8
  kernel:  Call Trace:
  kernel:  [&lt;ffffffff8105ca34&gt;] ? find_busiest_group+0x244/0x9e0
  kernel:  [&lt;ffffffff8152a8c5&gt;] schedule_timeout+0x215/0x2e0
  kernel:  [&lt;ffffffff8152a543&gt;] wait_for_common+0x123/0x180
  kernel:  [&lt;ffffffff81064b90&gt;] ? default_wake_function+0x0/0x20
  kernel:  [&lt;ffffffff8152a65d&gt;] wait_for_completion+0x1d/0x20
  kernel:  [&lt;ffffffff81098bf7&gt;] flush_work+0x77/0xc0
  kernel:  [&lt;ffffffff81098460&gt;] ? wq_barrier_func+0x0/0x20
  kernel:  [&lt;ffffffff81098e14&gt;] flush_delayed_work+0x54/0x70
  kernel:  [&lt;ffffffff813392f5&gt;] tty_flush_to_ldisc+0x15/0x20
  kernel:  [&lt;ffffffff81333cc7&gt;] n_tty_poll+0x67/0x1d0
  kernel:  [&lt;ffffffff8132f80a&gt;] tty_poll+0x8a/0xa0
  kernel:  [&lt;ffffffff811a6895&gt;] do_select+0x3c5/0x7c0
  kernel:  [&lt;ffffffff8149cf18&gt;] ? ip_finish_output+0x148/0x310
  kernel:  [&lt;ffffffff811a59f0&gt;] ? __pollwait+0x0/0xf0
  kernel:  [&lt;ffffffff811a5ae0&gt;] ? pollwake+0x0/0x60
  kernel:  [&lt;ffffffff811a5ae0&gt;] ? pollwake+0x0/0x60
  kernel:  [&lt;ffffffff811a5ae0&gt;] ? pollwake+0x0/0x60
  kernel:  [&lt;ffffffff811a5ae0&gt;] ? pollwake+0x0/0x60
  kernel:  [&lt;ffffffff8152d04b&gt;] ? _spin_unlock_bh+0x1b/0x20
  kernel:  [&lt;ffffffff8144b835&gt;] ? release_sock+0xe5/0x110
  kernel:  [&lt;ffffffff814a52cc&gt;] ? tcp_sendmsg+0x73c/0xa20
  kernel:  [&lt;ffffffff8144a72b&gt;] ? sock_aio_write+0x19b/0x1c0
  kernel:  [&lt;ffffffff8133158d&gt;] ? tty_wakeup+0x3d/0x80
  kernel:  [&lt;ffffffff811a6e1a&gt;] core_sys_select+0x18a/0x2c0
  kernel:  [&lt;ffffffff8109eb00&gt;] ? autoremove_wake_function+0x0/0x40
  kernel:  [&lt;ffffffff811a71a7&gt;] sys_select+0x47/0x110
  kernel:  [&lt;ffffffff810e5c87&gt;] ? audit_syscall_entry+0x1d7/0x200
  kernel:  [&lt;ffffffff810e5a7e&gt;] ? __audit_syscall_exit+0x25e/0x290
  kernel:  [&lt;ffffffff8100b072&gt;] system_call_fastpath+0x16/0x1b
  </code></pre>
  
  <p>So, looking at the last 2 function calls, it seems that the task is scheduled to sleep for some time via schedule_timeout(), and after that  find_busiest_group tries to balance the load which is generated by that task. Is it correct or is it something I am missing here?</p>
  
  <p>Thanks.</p>