Re: Ctrl+C doesn't interrupt process waiting for I/O

[Joe Peterson <joe@skyrush.com>]

Alan Cox wrote:
>> seems that the following two calls do the same thing in n_tty.c:
>> 		n_tty_flush_buffer(tty);
>> 		tty_driver_flush_buffer(tty);
> 
> Sorry missed this originally - they don't do the same thing. The first
> clears out anything in the ldisc internally the second clears out
> anything in the tty driver itself.

Alan, before I wrote this, I had put a printk() in n_tty_flush_buffer()
and noticed it was called twice when ^C was hit in an xterm.  Then I did
some investigating into this a few days ago, putting a dump_stack() in
n_tty_flush_buffer() so I could see how it is being called.

I realized the calls indeed have different purposes at that point.  I
still wonder, though, why when processing a ^C in an xterm/pty,
n_tty_flush_buffer() does get called again from the driver call.  See
the two traces below from the ldisc and driver flushes:

***********  CTRL-C received
Pid: 4669, comm: xterm Not tainted 2.6.26-rc8-git3 #1
 [<c0283126>] n_tty_flush_buffer+0xd/0x67
 [<c028385c>] n_tty_receive_buf+0x398/0xd87
 [<c031824b>] ? sock_aio_read+0xed/0xfb
 [<c017a824>] ? do_sync_read+0xab/0xe9
 [<c0136257>] ? hrtimer_forward+0xd6/0xec
 [<c0285569>] pty_write+0x2d/0x3b
 [<c0283450>] write_chan+0x21b/0x28f
 [<c011bfa4>] ? default_wake_function+0x0/0xd
 [<c028103f>] tty_write+0x14e/0x1be
 [<c0283235>] ? write_chan+0x0/0x28f
 [<c017a8ec>] ? rw_verify_area+0x8a/0xad
 [<c0280ef1>] ? tty_write+0x0/0x1be
 [<c017ae88>] vfs_write+0x8c/0x133
 [<c017b48c>] sys_write+0x3b/0x60
 [<c0103aa3>] sysenter_past_esp+0x78/0xb1
 =======================
Pid: 4669, comm: xterm Not tainted 2.6.26-rc8-git3 #1
 [<c02857c5>] ? pty_unthrottle+0x15/0x21
 [<c0283126>] n_tty_flush_buffer+0xd/0x67
 [<c0285663>] pty_flush_buffer+0x20/0x67
 [<c038ae61>] ? _spin_unlock_irqrestore+0x1b/0x2f
 [<c0284934>] tty_driver_flush_buffer+0x13/0x15
 [<c0283863>] n_tty_receive_buf+0x39f/0xd87
 [<c031824b>] ? sock_aio_read+0xed/0xfb
 [<c017a824>] ? do_sync_read+0xab/0xe9
 [<c0136257>] ? hrtimer_forward+0xd6/0xec
 [<c0285569>] pty_write+0x2d/0x3b
 [<c0283450>] write_chan+0x21b/0x28f
 [<c011bfa4>] ? default_wake_function+0x0/0xd
 [<c028103f>] tty_write+0x14e/0x1be
 [<c0283235>] ? write_chan+0x0/0x28f
 [<c017a8ec>] ? rw_verify_area+0x8a/0xad
 [<c0280ef1>] ? tty_write+0x0/0x1be
 [<c017ae88>] vfs_write+0x8c/0x133
 [<c017b48c>] sys_write+0x3b/0x60
 [<c0103aa3>] sysenter_past_esp+0x78/0xb1
 =======================

In a Linux virtual console/tty, however, the tty driver flush doesn't
call the ldisc flush again in my tests:

***********  CTRL-C received
Pid: 6, comm: events/0 Not tainted 2.6.26-rc8-git3 #1
 [<c0283126>] n_tty_flush_buffer+0xd/0x67
 [<c028385c>] n_tty_receive_buf+0x398/0xd87
 [<c038ab32>] ? _spin_lock_irqsave+0x27/0x41
 [<c038ab32>] ? _spin_lock_irqsave+0x27/0x41
 [<c038ae61>] ? _spin_unlock_irqrestore+0x1b/0x2f
 [<c027f3ee>] ? tty_ldisc_try+0x2f/0x35
 [<c027f9e2>] flush_to_ldisc+0xde/0x14d
 [<c013129d>] run_workqueue+0x78/0x102
 [<c027f904>] ? flush_to_ldisc+0x0/0x14d
 [<c0131a0b>] ? worker_thread+0x0/0xbf
 [<c0131abf>] worker_thread+0xb4/0xbf
 [<c0133f4d>] ? autoremove_wake_function+0x0/0x33
 [<c0133e77>] kthread+0x3b/0x64
 [<c0133e3c>] ? kthread+0x0/0x64
 [<c0104753>] kernel_thread_helper+0x7/0x10
 =======================


						-Joe