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
| ||
|
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/
Powered by blists - more mailing lists