linux-kernel - Re: Visible Ctrl-C in latest kernels

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:	Mon, 25 Aug 2008 12:03:21 -0600
From:	Joe Peterson <joe@...rush.com>
To:	David Newall <davidn@...idnewall.com>
CC:	Willy Tarreau <w@....eu>, Chris Frey <cdfrey@...rsquare.net>,
	Vegard Nossum <vegard.nossum@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Visible Ctrl-C in latest kernels

David Newall wrote:
> Willy Tarreau wrote:
>> I would not be surprized that it is what has caused delays for Ctrl-C
>> to take effect for some of us. As discussed in another thread on the
>> subject, the problem was relatively recent and not easy to reproduce.
>>   
> 
> I don't think so.  Joe Peterson raised A line of enquiry, which looked
> quite promising to me, in
> http://marc.info/?l=linux-kernel&m=121502197008293.  He observed weird
> behaviour with pgrp, and that doesn't seem to have been explored
> adequately.  I think it's worth highlighting that the code which sends
> the signal is the following snippet, from n_tty.c:
> 
>     if (tty->pgrp)
>             kill_pgrp(tty->pgrp, signal, 1);
> 
> 
> I wonder if pgrp has a value different than we expect?

David,

Subsequently, I determined that the issue I talked about in the above
referenced thread was a bug in bash.  Here is my post about this:

	http://marc.info/?l=linux-kernel&m=121537020432289&w=2

The bash author has developed a simple patch, and it should appear
(according to him) in the new bash version.

> I had an idea; it didn't work out as I expected, but it did produce a
> result that I can't immediately explain; and it might be relevant.  The
> following program, when executed in background (./testprogram &) stops
> at tcsetpgrp(), which is fine; and if then continued (fg), it is immune
> to the interrupt, quit and suspend keys.  However, it is not immune to
> those keys if executed in foreground (./testprogram).  As said, I can't
> immediately explain this, and it seems like it might be important...

When I run your program, foreground or background, it always completes
(i.e. 5 "." chars) - i.e., I cannot interrupt it before it finishes.
This seems different than what you see.

Given the nature of the bash issue, it does not seem related, at least
not directly.

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