Re: Bug with USB proc_bulk in 2.4 kernel

[Pete Zaitcev <zaitcev@redhat.com>]

On Mon, 10 Jul 2006 12:58:32 -0700, Benjamin Cherian <benjamin.cherian.kernel@gmail.com> wrote:

> I understand your decision but this does not follow the USB spec. According 
> to the spec, two threads should be able to perform operations on the same 
> device at the same time.

This consideration is wholly irrelevant to the pertinent topic,
because the very issue arises from devices being non-compliant.
If we want them to operate, we have to apply workarounds, which
may but us outside of the spec envelope. So I am not even going
to argue if the spec in fact mandates this behaviour.

> > But it seems to me that the best approach would be if you made
> > a special case for bulk+bulk and locked out control transfers somehow.
> 
> This is exactly what I suggested in my first email. It just involves adding a 
> couple of lines of code, but I'm not sure how the unlock function works in 
> 2.4. In 2.6, the device is unlocked WITHIN proc_bulk before usb_bulk_mesg is 
> called and is locked after usb_bulk_mesg returns. Therefore, the device is 
> still locked during control transfers.

I explained why this technique is not applicable to 2.4 in the part
of the message you failed to quote. To recap, if bulk methods were
simply to drop locks with a "couple of lines of code", they would allow
control transfers to happen simultaneously with bulk transfers.
It happens to work in 2.6 only because of its string caching feature.
Indeed, Stuart Hayes of Dell reported that he can cause TEAC CD-210PU
to break under 2.6.16 in the same way it did in 2.4.27, simply by doing
"lsusb -v" instead of "cat /proc/bus/usb/devices". The issue is still
with us. Greg chose to bypass it in 2.6, instead of fixing it, due
to the amount of work involved.

This is a fixable issue, but it's not two lines of code. And its
impact is very limited. If you, the person who actually suffers, are
not willing to do the necessary work, then why would anyone else be?
Still, I would be happy to consider your patch, if it were to emerge.

-- Pete