lkml.org 
[lkml]   [2006]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Bug with USB proc_bulk in 2.4 kernel and possibly bug in proc_ioctl in 2.6
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-07-08 22:31    [W:0.316 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site