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]

Date:	Sat, 5 May 2007 17:11:52 +0200
From:	"Antonino Ingargiola" <tritemio@...il.com>
To:	"Paul Fulghum" <paulkf@...rogate.com>
Cc:	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	linux-usb-users@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

2007/5/5, Paul Fulghum <paulkf@...rogate.com>:
> On Fri, 2007-05-04 at 17:30 -0600, Paul Fulghum wrote:
> > OK, this behavior is so unexpected I must be missing
> > something basic.
>
> And so I was. Try this patch.
>
> --- a/drivers/char/tty_io.c     2007-05-04 05:46:55.000000000 -0500
> +++ b/drivers/char/tty_io.c     2007-05-05 03:23:46.000000000 -0500

Great! Really good job, Paul. The patch now boot properly and solves
completely the testcase with two serial lines:

	In [1]: import serial
	In [2]: s0 = serial.Serial(0, timeout=1)
	In [3]: s1 = serial.Serial(1, timeout=1)
	In [4]: s0.write('test\n')
	In [5]: s1.inWaiting()
	Out[5]: 5L
	In [6]: s1.readline()
	Out[6]: 'test\n'
	In [7]: for i in xrange(1000):
	   ...:     s0.write(str(i).zfill(8)+'\n')
	   ...:
	In [8]: s1.inWaiting()
	Out[8]: 4095L
	In [9]: s1.flushInput()
	In [10]: s1.inWaiting()
	Out[10]: 0L
	In [11]: s0.write('test\n')
	In [12]: s1.inWaiting()
	Out[12]: 5L
	In [13]: s1.readline()
	Out[13]: 'test\n'

I've done more tests with other scripts and all works perfectly (the
input buffer is really totally flushed the first time). Many thanks! I
think this patch should be included in mainline, since if one flushes
the input buffer, really want to flush the entire buffer chain and
doesn't want to read any old data _after_ a flush.

However I also tested a usb-serial device (that uses the cdc-acm
driver) and in this case I still need _two_ flushInput() to totally
flush the input buffer.

There can be another *secondary buffer* in the usb-serial driver? Can
this buffer be emptied out too?

I bet the same behavior can be reproduced with another FTDI-based
usb-serial device that I haven't at hand now (but that I can test the
next week).

Many thanks for the help so far.

Regards,

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