Bug with USB proc_bulk in 2.4 kernel and possibly bug in proc_ioctl in 2.6

Bug with USB proc_bulk in 2.4 kernel and possibly bug in proc_ioctl in 2.6

[Benjamin Cherian]

I believe that there is a bug in the proc_bulk function in drivers/usb/devio.c 
in the current 2.4 kernel. In the 2.4.28 proc_ioctl was changed so that the 
device would be locked before proc_bulk was called (See line 1275 of 
devio.c). In 2.4.27, no locking occurred. However, this leads to problems if 
one thread is continuously attempting to read and another one needs to write 
because the write thread can never access the device. The code has changed a 
little since 2.4.28, but the device is still locked before proc_bulk is 
called.

In the 2.6 kernel,the device is locked before proc_bulk, or any other USB 
operation for that matter, is called (see line 1419 in 
drivers/usb/core/devio.c); however, the device is unlocked in proc_bulk 
before usb_bulk_msg is called, and is locked after usb_bulk_msg is completed. 
(See lines 716-718 & 746-748 of v2.6 devio.c)

Additionally, in 2.4.32 one of the comments says that for some ioctls, the 
device does not need to be locked because they don't touch the device (e.g. 
USBDEVFS_REAPURB or USBDEVFS_GETDRIVER, see 2.4.32 for more). However, in 2.6 
the device is locked for all ioctls. Shouldn't this be changed?

I would have submitted a patch, but it seems like the locking/unlocking 
mechanism is different in 2.4 and 2.6 and I wasn't sure if I would break 
other stuff.



Thanks,

Ben

Re: Bug with USB proc_bulk in 2.4 kernel and possibly bug in proc_ioctl in 2.6

[Pete Zaitcev]

On Fri, 7 Jul 2006 17:24:56 -0700, Benjamin Cherian <benjamin.cherian.kernel@gmail.com> wrote:

> I believe that there is a bug in the proc_bulk function in drivers/usb/devio.c 
> in the current 2.4 kernel. In the 2.4.28 proc_ioctl was changed so that the 
> device would be locked before proc_bulk was called (See line 1275 of 
> devio.c). In 2.4.27, no locking occurred. However, this leads to problems if 
> one thread is continuously attempting to read and another one needs to write 
> because the write thread can never access the device. []

The decision to cripple the devio in this way was conscious. The problem
scenario with 2.4.27 and earlier was how many devices would fail if
a control and other transfer were submitted simultaneously. In other
words, when desktop components (e.g. HAL) rescanned /proc/bus/usb/devices,
some other devices would throw errors. The most notorious example
would be TEAC CD-210PU, because of how widespread and popular it is.

In other words, I crippled your application for the sake of a bunch
of users of other devices. You have to realize though, that your
concerns weren't voiced in the time and it was widely believed that
user-mode drivers did not submit several URBs at once (primarily
because the queueing in HCDs of 2.4 was a suspect).

> I would have submitted a patch, but it seems like the locking/unlocking 
> mechanism is different in 2.4 and 2.6 and I wasn't sure if I would break 
> other stuff.

If you do send a patch, you need to account for the serialization
somehow. The linux-usb-devel people considered a few ideas, such
as per-device blacklists and locking flags, backport of string caching
from 2.6 (to alleviate the most common case of /proc/usb/usb/devices).

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.

Another option is to look at an in-kernel driver architecture for
your device. What is it, anyway?

-- Pete