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:	Sat, 05 Jul 2008 14:49:47 +0200
From:	Elias Oltmanns <eo@...ensachen.de>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Joe Peterson <joe@...rush.com>,
	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

The discussion seems to have become a little heated, so allow me to step
in here ...

Andi Kleen <andi@...stfloor.org> wrote:
> Alan Cox wrote:
[...]
>  I can't reproduce it, nobody has provided
>> numbers so even if I wanted to work on it I couldn't do much.
>
> Well we had a patch (although I haven't tried it yet)
>
> http://marc.info/?l=linux-kernel&m=121489861508496&w=2
>
> Is that not concrete enough?

Actually, I'm not to sure whether this really fixes the root cause of
the problem -- I never have been and I meant to indicate as much in my
email. It's been the first time I looked at the tty code and the patch
was mainly guess work; all it does is reverting parts of a previous
patch. My hope was to direct other people's (read: those who no the tty
code) attention to a change that seemed to cause the problem. Perhaps I
didn't make it clear enough at the time that I didn't really know *why*
this change should cause any problem in the first place.

Now, the situation has become even more delicate. Joe has reported that
my patch breaks echoing in the xterm and, rather to my embarrassment, I
have to report that it doesn't even fix the issue I claumed it would.
All it apparently does is making the problem slightly harder to
reproduce which is why it didn't occur in my tests at the time.

Since I have been concentrating on other things over the last days, it's
been only today that I discovered this. Moreover, some more testing lead
me to believe that the root issue has been present in mainline at least
since 2.6.19 and Joe's change in 2.6.25 only made it visible because you
now occasionally get something like
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z

on your screen when you keep pressing Ctrl+Z until the prompt appears;
in 2.6.24, for instance, there would just be a short delay but no
irritating output on the screen that makes you wonder.

Quite frankly, I'm a bit at a loss as to how I should go about debugging
this and what kind of data might be useful to others to do so. In
another email Alan talked about latency traces which is something new to
me. Since the OP talked about latencytop, I hope that this tool provides
the data Alan requires and will install and make use of it accordingly
(expect some results later today or tomorrow). Of course, I'm always
open to other / additional suggestions.

Regards,

Elias
--
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/