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

[Joe Peterson]

Elias Oltmanns wrote:
>> 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.

I have tried to reproduce the original poster's issue on
2.6.26-rc8-git3 without success.  In around 100 attempts (restarting the
disk activity process over each time it completed), it always broke out
after one ^C - one time took an extra second or two.  Note that I did
not run latencytop (did not have it compiled in my kernel) - if that is
required for the test, let me know, but I assume it is just for
gathering info when the issue occurs.

Can you please try something for me?  For one, apply the attached patch,
which removes what seems to be a redundant flush (since both calls end
up calling the same n_tty routine).  This made no difference for me, but
I am curious if it might help you.

If you still see the problem, please try typing "stty noflsh" and try
again.  This disables the flush step, which may be affecting you.
Again, this did not make a difference for me.

It will really help me to know the results of these steps for you.

As far as moving the flush after the signal, I have tried this (in the
patch I posted earlier), and it ends up causing various anomalies in
output, so I do not think that is the right solution.

						-Joe

--- linux/drivers/char/n_tty.c.orig	2008-07-04 09:45:37.000000000 -0600
+++ linux/drivers/char/n_tty.c	2008-07-04 11:25:38.000000000 -0600
@@ -589,10 +589,8 @@
 {
 	if (tty->pgrp)
 		kill_pgrp(tty->pgrp, sig, 1);
-	if (flush || !L_NOFLSH(tty)) {
+	if (flush || !L_NOFLSH(tty))
 		n_tty_flush_buffer(tty);
-		tty_driver_flush_buffer(tty);
-	}
 }
 
 /**
@@ -765,10 +763,8 @@
 			 * the order to be:
 			 * 1) flush, 2) echo, 3) signal
 			 */
-			if (!L_NOFLSH(tty)) {
+			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)