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]

Message-ID: <87fxqurqpz.fsf@denkblock.local>
Date:	Tue, 01 Jul 2008 09:47:04 +0200
From:	Elias Oltmanns <eo@...ensachen.de>
To:	Török Edwin <edwintorok@...il.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Joe Peterson <joe@...rush.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: Ctrl+C doesn't interrupt process waiting for I/O

Török Edwin <edwintorok@...il.com> wrote:
> Hi,
>
> I have encountered the following situation several times, but I've been
> unable to come up with a way to reproduce this until now:
>  - some process is keeping the disk busy (some cron job for example:
> updatedb, chkrootkit, ...)
>  - other processes that want to do I/O have to wait (this is normal)
>  - I have a (I/O bound) process running in my terminal, and I want to
> interrupt it with Ctrl+C
>  - I type Ctrl+C several times, and the process is not interrupted for
> several seconds (10-30 secs)
>  - if I type Ctrl+Z, and use kill %1 the process dies faster than
> waiting for it to react to Ctrl+C

The following patch to 2.6.26-rc8 fixes the issue for me. Perhaps we
really want to do something else, but since I'm not all that familiar
with the standard behaviour on other Unices and since the comment
describing the changed order of function calls in the original commit
didn't give the reason for that change, I leave that to more
knowledgeable people.

Regards,

Elias


--------
From: Elias Oltmanns <eo@...ensachen.de>
Subject: Make sure that interrupt characters get through reliably

Since commit ec5b1157f8e819c72fc93aa6d2d5117c08cdc961, users have been
unable to interrupt interactive processes reliably by pressing CTRL+C.
This patch reverts the original commit except for the most important
part: actually echoing ^C is preserved.

Signed-off-by: Elias Oltmanns <eo@...ensachen.de>
---

 drivers/char/n_tty.c |   13 +------------
 1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/drivers/char/n_tty.c b/drivers/char/n_tty.c
index 8096389..74018ef 100644
--- a/drivers/char/n_tty.c
+++ b/drivers/char/n_tty.c
@@ -759,20 +759,9 @@ static inline void n_tty_receive_char(struct tty_struct *tty, unsigned char c)
 		signal = SIGTSTP;
 		if (c == SUSP_CHAR(tty)) {
 send_signal:
-			/*
-			 * Echo character, and then send the signal.
-			 * Note that we do not use isig() here because we want
-			 * the order to be:
-			 * 1) flush, 2) echo, 3) signal
-			 */
-			if (!L_NOFLSH(tty)) {
-				n_tty_flush_buffer(tty);
-				tty_driver_flush_buffer(tty);
-			}
 			if (L_ECHO(tty))
 				echo_char(c, tty);
-			if (tty->pgrp)
-				kill_pgrp(tty->pgrp, signal, 1);
+			isig(signal, tty, 0);
 			return;
 		}
 	}
--
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/