linux-kernel - Re: Strange problem with tty layer

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, 26 Jan 2007 09:20:41 -0500
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Paul Fulghum <paulkf@...rogate.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Strange problem with tty layer

On Thu, Jan 25, 2007 at 10:16:39AM -0500, Lennart Sorensen wrote:
> I am now trying this, which so far seem to help (I had a printk in there
> earlier and managed to trigger that).
> 
> --- ori/drivers/char/tty_io.c	2007-01-24 18:02:48.000000000 -0500
> +++ new/drivers/char/tty_io.c	2007-01-25 09:50:02.000000000 -0500
> @@ -2774,6 +2778,14 @@
>  	spin_lock_irqsave(&tty->buf.lock, flags);
>  	while((tbuf = tty->buf.head) != NULL) {
>  		while ((count = tbuf->commit - tbuf->read) != 0) {
> +			if (!tty->receive_room) {
> +				schedule_delayed_work(&tty->buf.work, 1);
> +				spin_unlock_irqrestore(&tty->buf.lock, flags);
> +				goto out;
> +			}
> +			if (count > tty->receive_room) {
> +				count = tty->receive_room;
> +			}
>  			char_buf = tbuf->char_buf_ptr + tbuf->read;
>  			flag_buf = tbuf->flag_buf_ptr + tbuf->read;
>  			tbuf->read += count;
> 
> This appeared to be (essentially) the key change in 2.6.18 related to
> the check of tty->receive_room.
> 
> I will now run a bunch more tests to see if it manages to keep it from
> having any more character losses.
> 
> Thank you for the suggestion of where to look.

Well it turns out that didn't help.  Neither does 2.6.18 (that one was
the easiest newer one to try).  It does seem as if the error rate is
lower with 2.6.18 than with 2.6.16, so perhaps there was more than one
place that could cause losses in the tty buffering.  I had only 2
failures in 15 hours with 2.6.18, rather than a whole lot of failures
with 2.6.16.  I guess I will have to try 2.6.19 or even something newer.

--
Len Sorensen
-
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/