linux-kernel - Re: serial flow control appears broken

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]

Message-ID: <Pine.LNX.4.64N.0707301023150.12082@blysk.ds.pg.gda.pl>
Date:	Mon, 30 Jul 2007 10:34:36 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Robert Hancock <hancockr@...w.ca>
cc:	Lee Howard <faxguy@...ardsilvan.com>, linux-serial@...r.kernel.org,
	tytso@....edu, rmk@....linux.org.uk, linux-kernel@...r.kernel.org
Subject: Re: serial flow control appears broken

On Fri, 27 Jul 2007, Robert Hancock wrote:

> > The TTY line discipline driver could do that based on the amount of received
> > data present in its buffer.  And it should if asked to (a brief look at
> > drivers/char/n_tty.c reveals it does; obviously there may be a bug 
> 
> Really, where? In my look through the code I haven't found any mechanism that
> would result in RTS being lowered based on TTY buffers filling up, at least
> not in the 8250 case.

 Look for calls to ->throttle() and ->unthrottle().  XON and XOFF might be 
used instead as a result of these calls though, depending on terminal 
settings.

> In this situation, though, it appears it's not the TTY buffers that are
> filling but the UART's own buffer. I would think this must be caused by some
> kind of interrupt latency that results in not draining the FIFO in time.

 Well, the UART only has its FIFO which is rather small, so automatic flow 
control would be useful.  Though, admittedly, tty_insert_flip_char() might 
return some kind of a status related to how much space is left in the 
receive buffer which would indicate that there is a lag in data stream 
processing -- which in turn may relate to the system being loaded, so that 
the receive ISR could decide whether to negate RTS itself for the less 
capable UARTs (i.e. ones with no autoflow and a tiny or no FIFO).

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