/drivers/char/n_tty.c drops characters

[Denis Joseph Barrow]

Hi all,
While I may be taking this out of context but
from a git log on include/linux/tty_ldisc.c Alan Cox says. 

>  Finally many drivers had invalid and unsafe attempts to avoid buffer
>     overflows by directly invoking tty methods extracted out of the innards
>     of work queue structs. These are no longer needed and all go away. That
>     fixes various random hangs with serial ports on overflow.

Maybe my interpretation of this statement is incorrect but
is Alan implying that ttys will no longer drop charaters ? 
if this is what Alan is saying it is simply not true but it can be implemented.

If tty's use the /drivers/char/n_tty.c line discipline.
a quick look at drivers/char/tty_io.c sees that
tty_flip_buffer_push calls directly or indirectly flush_to_ldisc
which in turns copies to disc->ops->receive_buf normally n_tty_receive_buf
which normally is the ntty line discipline ( the default )

The simplest code path to follow in n_tty_receive_buf if tty->real_raw is set is
below
	if (tty->real_raw) {
		spin_lock_irqsave(&tty->read_lock, cpuflags);
		i = min(N_TTY_BUF_SIZE - tty->read_cnt,
			N_TTY_BUF_SIZE - tty->read_head);
		i = min(count, i);
		memcpy(tty->read_buf + tty->read_head, cp, i);
		tty->read_head = (tty->read_head + i) & (N_TTY_BUF_SIZE-1);
		tty->read_cnt += i;
		cp += i;
		count -= i;

		i = min(N_TTY_BUF_SIZE - tty->read_cnt,
			N_TTY_BUF_SIZE - tty->read_head);
		i = min(count, i);
		memcpy(tty->read_buf + tty->read_head, cp, i);
		tty->read_head = (tty->read_head + i) & (N_TTY_BUF_SIZE-1);
		tty->read_cnt += i;
		spin_unlock_irqrestore(&tty->read_lock, cpuflags);
	}

My understanding of this code might be imperfect but this really looks
likes this blindly copies into a ring buffer of N_TTY_BUF_SIZE &
doesn't return any indication an attempt to copy a tty buffer of larger than N_TTY_BUF_SIZE
& overflows the buffer before the task activated by the code at the bottom of n_tty_receive_buf

i.e.
if (waitqueue_active(&tty->read_wait))
			wake_up_interruptible(&tty->read_wait);
which typically wakes up the read_chan function in the same file.

The main things I see wrong with this code is performance
& dropping characters from serial devices, this which might be quite
acceptable for reading keystrokes but is not for high speed modems.

My main complaints are
1) there is no mechanism for informing the tty layer that not all the
characters are copied from the tty layer to the line discipline.

2) The use of a a ring buffer in the line discipline,
we are memcpying at least twice in the kernel before passing the
buffer back to userland.

3) There is no mechanism for tty_io.c of informing the
char driver which is feeding the tty that it can
release flow control & start feeding read buffers
to the device hardware again to restart io. 

Less important points in point 3.
In my attempts I gave up on
I wrapped disc->ops->receive_buf with my own receive_buf
callback but this would break if the line discipline changed.

I also accidently made my code recursive because I was
calling calling tty_flip_buf calling disc->ops_receive buf
again & stealing a lock again as the tty->low_latency
flag was set in the driver, so the developer should be
warned not to use this flag if we put the callback to
start flow control in flush_to_line_disc.

Maybe it might be an idea to have a user settable minimum
characters available in the tty_layer before the callback
gets done.

4) Maybe the tty_io layer should be using a ring buffer
but this is just a silly & probably plain wrong opinion of mine.

I currently don't know this code & all the line disciplines
well enough to fix this code reliably & I think for all the
line discipline be a patch of over 300 lines. I don't think
I have the street cred to get a patch like this into such a critical part
of the mainstream kernel & probably rightly so.


-- 
best regards,
D.J. Barrow
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/