All of lore.kernel.org
 help / color / mirror / Atom feed
From: Elias Oltmanns <eo@nebensachen.de>
To: Joe Peterson <joe@skyrush.com>
Cc: "Török Edwin" <edwintorok@gmail.com>,
	"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
	"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: Ctrl+C doesn't interrupt process waiting for I/O
Date: Tue, 01 Jul 2008 16:48:33 +0200	[thread overview]
Message-ID: <877ic5irsu.fsf@denkblock.local> (raw)
In-Reply-To: <486A3B4A.2090005@skyrush.com> (Joe Peterson's message of "Tue, 01 Jul 2008 08:12:26 -0600")

Joe Peterson <joe@skyrush.com> wrote:
> Elias Oltmanns wrote:
>> 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.
>> 
>>  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;
>>  		}
>>  	}
>
> I noticed the original post in this thread mentioned that the problem
> has been seen since 2.6.21 or 2.6.23:
>
>> I use 2.6.25-2 and 2.6.26-rc8 now; I don't recall seeing this
>> behaviour with old kernels (IIRC I see this since 2.6.21 or 2.6.23).
>>
>> Is this intended behaviour, or should I report a bug?
>
> The echo patch that is altered in the patch above only appeared recently
> (in 2.6.25).  Is there a way for you try try the test case on a
> pre-2.6.25 kernel and see if the issue exists there?  If so, it is
> strange that the above fixes it.

Due to my tests, 2.6.24 responds much faster to Ctrl+C than 2.6.25 does.
The patch above makes them *feel* alike again (no hard numbers, mind).
However, I haven't checked anything as early as 2.6.21 or before so I
don't know whether there may have been another regression since then.

Regards,

Elias

  reply	other threads:[~2008-07-01 14:49 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-28 10:38 Ctrl+C doesn't interrupt process waiting for I/O Török Edwin
2008-06-29  2:44 ` Jeremy Fitzhardinge
2008-06-29  2:45   ` Jeremy Fitzhardinge
2008-06-29  3:42   ` Avi Kivity
2008-06-29  5:13     ` Jeremy Fitzhardinge
2008-06-29  5:39       ` Avi Kivity
2008-06-29  6:25         ` Jeremy Fitzhardinge
2008-06-29  7:45           ` Török Edwin
2008-06-29 23:57           ` Bill Davidsen
2008-06-29 12:37         ` Alan Cox
2008-06-30 17:35       ` J. Bruce Fields
2008-06-29  7:09   ` Török Edwin
2008-06-29  7:23   ` David Newall
2008-06-29 12:10   ` Andi Kleen
2008-06-29 16:02     ` Jeremy Fitzhardinge
2008-06-30 10:30       ` Helge Hafting
2008-07-01  7:47 ` Elias Oltmanns
2008-07-01  8:02   ` Elias Oltmanns
2008-07-01  8:28     ` Török Edwin
2008-07-01  9:59       ` Elias Oltmanns
2008-07-01 12:07       ` Joe Peterson
2008-07-01  8:50   ` David Newall
2008-07-01  9:01     ` Török Edwin
2008-07-01  9:12       ` David Newall
2008-07-01 14:12   ` Joe Peterson
2008-07-01 14:48     ` Elias Oltmanns [this message]
2008-07-01 16:27       ` Joe Peterson
2008-07-02 21:26   ` Joe Peterson
2008-07-04 20:10   ` Joe Peterson
2008-07-04 20:23     ` Alan Cox
2008-07-04 21:17       ` Joe Peterson
2008-07-11 14:47         ` Alan Cox
2008-07-12  0:44           ` Joe Peterson
2008-07-12 10:37             ` Alan Cox
2008-07-04 21:21       ` Andi Kleen
2008-07-04 21:14         ` Alan Cox
2008-07-04 21:36           ` Andi Kleen
2008-07-04 21:44             ` Alan Cox
2008-07-04 22:09               ` Andi Kleen
2008-07-05 10:34                 ` Alan Cox
2008-07-05 11:00                   ` Andi Kleen
2008-07-05 11:34                     ` Alan Cox
2008-07-05 12:49                     ` Elias Oltmanns
2008-07-05 14:01                       ` Andi Kleen
2008-07-05 19:58                       ` Joe Peterson
2008-07-06  8:28                         ` Elias Oltmanns
  -- strict thread matches above, loose matches on Subject: below --
2008-07-03  0:59 Matthew Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877ic5irsu.fsf@denkblock.local \
    --to=eo@nebensachen.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=edwintorok@gmail.com \
    --cc=joe@skyrush.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.