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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 Jul 2008 18:44:12 -0600
From:	Joe Peterson <joe@...rush.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Elias Oltmanns <eo@...ensachen.de>,
	Török Edwin <edwintorok@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: Ctrl+C doesn't interrupt process waiting for I/O

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/