lkml.org 
[lkml]   [2003]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
Date
On Wednesday 10 December 2003 18:21, David Brownell wrote:
> [ CC list trimmed, most folk are on one of the cc'd lists ]
>
> > By the way, here is the list of routines that cause trouble for usbfs:

Hi Dave, by "they cause trouble" I meant: they may take, or lead to
taking, dev->serialize. This means that before my patch they could
lead to occasional deadlocks, and with my patch will always cause
deadlocks.

> > usb_probe_interface
>
> In proc_resetdevice() ... after usb_reset_device().
> If usb_reset_device() worked sanely, it wouldn't be
> necessary to try fixing up its result. Plus, last I
> looked, I don't think usbfs fixed it up correctly.
>
> Actually that call is dangerous and probably should
> fail if usbfs isn't controlling all the interfaces
> on the device ... checking before it tries.
>
> > usb_reset_device
>
> We've known for some time this routine needs a rewrite.
> It's never quite worked right, and it doesn't handle
> DFU style devices (like the most common USB 802.11b
> adapters) well at all.
>
> > usb_set_configuration
>
> That is, you're saying that _if_ usbfs is modified to
> get rid of ps->devsem and use dev->serialize instead,
> then you'd need some other way to guard proc_setconfig()
> against disconnect? That still seems like a chicken/egg
> issue to me.

No. usb_set_configuration takes dev->serialize, which is
already taken. There is no other problem.

> > usb_unbind_interface
>
> See the patch I posted yesterday evening, with usbfs parts
> of the updates to driver binding. It's incorrect for usbfs
> ever to be calling that ... device_release_driver() is the
> thing to call, for drivers that weren't bound using the
> usb_driver_claim_interface() call. That way the sysfs
> state also gets cleaned up ...

Yeah, these things are a mess. My patch only fixes the
locking problems, not the fact that they never worked
anyway. Even so, it may be hard to get it into 2.6.0.

Duncan.
-
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: 2005-03-22 13:59    [W:0.109 / U:1.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site