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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 24 Feb 2010 04:33:48 +0200
From:	Anssi Hannula <anssi.hannula@....fi>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Oliver Neukum <oliver@...kum.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 22:12:41 Alan Stern wrote:
> On Mon, 22 Feb 2010, Matthew Garrett wrote:
> > On Mon, Feb 22, 2010 at 02:10:33PM -0500, Alan Stern wrote:
> > > On Mon, 22 Feb 2010, Anssi Hannula wrote:
> > > > 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?
> > > 
> > > I don't know.  Didn't the old successful code use a tty interface?
> > 
> > Yes. The kfifo changes have caused some sort of alteration in behaviour.
> > 
> > > > Any idea what could be causing the hang, then?
> > > 
> > > No idea, unless it's the device.
> > 
> > Once the device hangs, it then tends to refuse any input until power
> > cycled. So it's clearly getting into some sort of undefined state,
> > though whether that's because it only gets sent half of its firmware
> > (ie, the hang occurs and as a result the hardware dies) or whether it's
> > causing the hang by dying is unclear.
> 
> The latest logs did show all the firmware getting sent -- or at least,
> they show that as much data was sent by the nonworking driver as by the
> working driver.  So I'd say the device causes the hang by dying,
> although I don't know where the hang is or why a dead device should
> cause it.

When the hang happens, the complete firmware is *not* sent to the device. The 
usbmon log is 10 times smaller:
http://stuff.onse.fi/gobi2000/gobi-regression2.mon.log
For reference, here's the hang with usbserial debug=1:
http://stuff.onse.fi/gobi2000/gobi-regression2.dmesg.log

The later logs were of runs that did not hang, but did still not work. I added 
descriptions here, in case someone is confused with all the logs (which I 
should've named better): http://stuff.onse.fi/gobi2000/

But if a device in corrupt state can cause such a hang, then it is likely that 
that is happening here (due to the packet bounding issue described in the 
other messages).

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