linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Buffer overflow concerns when TTY_THRESHOLD_THROTTLE <= Uart FIFO size of the sending side
@ 2013-08-09 21:08 Karthik Manamcheri
  2013-08-12 11:30 ` Peter Hurley
  0 siblings, 1 reply; 2+ messages in thread
From: Karthik Manamcheri @ 2013-08-09 21:08 UTC (permalink / raw)
  To: linux-serial

When using software-level RTS/CTS flow control (or Xon/Xoff), we could
leak at most the UART FIFO size of bytes after getting the flow
control signal. This is because the bytes might be loaded in the FIFO
when the flow control signal comes through and the UART will send them
out the wire.

Consider a case where I have a UART with a 128 byte FIFO. The
TTY_THRESHOLD_THROTTLE is set at 128 bytes in n_tty.c. So, isn't it
possible that potentially we lose bytes when moving data to the TTY
line discipline buffer? If the line discipline buffer is almost full
(say the receiving room is 120 bytes), it calls throttle and even if
the other end gets the throttle in time, it could potentially send 128
bytes (but there is only 120 bytes of space in the buffer). So when we
are flushing to ldisc, we will transfer only the receive_room amount
of data and discard the rest? Is there any way of avoiding this?

I know there is no way of knowing what the FIFO size of the other side
might be! I was wondering if this happens, could we potentially flag a
buffer overflow error? We know how many bytes are coming in from the
UART and when we are trying to flush to ldisc, if the count is more
than the throttle level, can we return an error?

Thanks,
Karthik

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Buffer overflow concerns when TTY_THRESHOLD_THROTTLE <= Uart FIFO size of the sending side
  2013-08-09 21:08 Buffer overflow concerns when TTY_THRESHOLD_THROTTLE <= Uart FIFO size of the sending side Karthik Manamcheri
@ 2013-08-12 11:30 ` Peter Hurley
  0 siblings, 0 replies; 2+ messages in thread
From: Peter Hurley @ 2013-08-12 11:30 UTC (permalink / raw)
  To: Karthik Manamcheri; +Cc: linux-serial

On 08/09/2013 05:08 PM, Karthik Manamcheri wrote:
> When using software-level RTS/CTS flow control (or Xon/Xoff), we could
> leak at most the UART FIFO size of bytes after getting the flow
> control signal. This is because the bytes might be loaded in the FIFO
> when the flow control signal comes through and the UART will send them
> out the wire.
>
> Consider a case where I have a UART with a 128 byte FIFO. The
> TTY_THRESHOLD_THROTTLE is set at 128 bytes in n_tty.c. So, isn't it
> possible that potentially we lose bytes when moving data to the TTY
> line discipline buffer? If the line discipline buffer is almost full
> (say the receiving room is 120 bytes), it calls throttle and even if
> the other end gets the throttle in time, it could potentially send 128
> bytes (but there is only 120 bytes of space in the buffer). So when we
> are flushing to ldisc, we will transfer only the receive_room amount
> of data and discard the rest? Is there any way of avoiding this?

Up to 64Kb of received data is buffered, so even if there is significant
delay throttling the sender, an overflow should not occur unless the bit
rate is in excess of 20Mbits/sec or so.

The receive buffer code is in drivers/tty/tty_buffer.c
The commonly used driver-side interface is tty_insert_flip_string() and
tty_flip_buffer_push(). flush_to_ldisc() is the work thread routine
which pushes this received data to the line discipline.

As far as I'm aware, only the synclink* drivers use the line discipline
interface directly (rather than the tty buffer interface) but perform
their own rx buffering.

Regards,
Peter Hurley

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-08-12 11:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-09 21:08 Buffer overflow concerns when TTY_THRESHOLD_THROTTLE <= Uart FIFO size of the sending side Karthik Manamcheri
2013-08-12 11:30 ` Peter Hurley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).