linux-kernel - Re: [REGRESSION] "USB: use kfifo to buffer usb-generic serial writes" causes gobi

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: <201002222035.36043.anssi.hannula@iki.fi>
Date:	Mon, 22 Feb 2010 20:35:35 +0200
From:	Anssi Hannula <anssi.hannula@....fi>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Oliver Neukum <oliver@...kum.org>,
	Matthew Garrett <mjg59@...f.ucam.org>, dvomlehn@...co.com,
	gregkh@...e.de, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] "USB: use kfifo to buffer usb-generic serial writes" causes gobi_loader to hang

On maanantai 22 helmikuu 2010 17:28:36 Alan Stern wrote:
> On Mon, 22 Feb 2010, Anssi Hannula wrote:
> > > > If I additionally insert a one-second delay before the fd is closed,
> > > > I get this usbmon log:
> > > > http://stuff.onse.fi/gobi2000/gobi-regression5.mon.log
> > > > 
> > > > The firmware upload is still unsuccessful.
> > > 
> > > If I use the option driver instead of qcserial, the firmware upload is
> > > always successful (without any added delays needed). The usbmon log for
> > > that case can be found here:
> > > http://stuff.onse.fi/gobi2000/gobi-regression6.mon.log
> > 
> > I installed 2.6.31.12 to get a usbmon log with qcserial before the
> > regression as well (without delays, upload successful):
> > http://stuff.onse.fi/gobi2000/gobi-regression7.mon.log
> 
> The major difference between the logs is in the way the data get
> divided up into packets.  In both the successful logs, there are
> sequences of bulk-OUT packets with lengths like:
> 
> 	44, 1, 15, 1, 13
> 
> where the unsuccessful transfer just has a single packet of length 74.
> Also, the successful transfers show a lot of bulk-IN traffic where the
> unsuccessful transfer doesn't have any.  I don't know if that is
> relevant, however.
> 
> No other differences stand out.

I guess that would suggest that the device doesn't allow the initialization 
data to be broken into packets arbitrarily (though some differences seem 
allowed, as the windows driver transmits them differently).

Does this mean a tty interface is ill-suited for the microcode upload, and 
instead qcserial should use the kernel's generic microcode upload mechanism or 
the userspace should use libusb to do it?

Any idea what could be causing the hang, then? The WARNING that appears when 
interrupting the hung gobi_loader is for serial_unthrottle() being called 
while usb_serial_port->port.count == 0.

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