Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1

[Duncan Sands <baldrick@free.fr>]

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.