linux-kernel - Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

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: <463DEAF8.1040607@microgate.com>
Date:	Sun, 06 May 2007 08:49:28 -0600
From:	Paul Fulghum <paulkf@...rogate.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Oliver Neukum <oliver@...kum.org>,
	Antonino Ingargiola <tritemio@...il.com>,
	linux-usb-users@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible
 bug]

Alan Cox wrote:
> On Sat, 5 May 2007 20:07:15 +0200
> Oliver Neukum <oliver@...kum.org> wrote:
>> should I understand this so that, if tty_buffer_request_room() returns
>> less than requested, the rest of the data should be dropped on the
>> floor?
> 
> If it returns NULL then either there is > 64K buffered (we can adjust
> that if anyone shows need - its just for sanity) or the system is out of
> RAM. 

It sounds bad, but I think dropping the data make sense with the
new tty buffering code.

My interpretation of the tty buffering is that
it is intended to be the main receive buffer facility
for the driver.

It simplifies and centralizes these functions so
the driver does not need implement policies such as when to
flush for user request, expand under load, crop when too large.

It should not be the driver's responsibility to
try and work around the tty buffering if it becomes full.
That adds other complexity such as when the driver should
attempt to push the data again: when more data is received?
after a timeout?

If the tty buffering runs dry, then maybe put out an error message.
If the losses occur too often then the tty buffering code needs to
be adjusted.

--
Paul

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