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, 04 Jul 2008 14:10:43 -0600
From:	Joe Peterson <joe@...rush.com>
To:	Elias Oltmanns <eo@...ensachen.de>
CC:	Török Edwin <edwintorok@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: Ctrl+C doesn't interrupt process waiting for I/O

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

View attachment "gentoo-sources-2.6.26-remove-redundant-flush.patch" of type "text/x-patch" (628 bytes)