On Thu, May 16, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > I took a look at it (ref-fixup.patch) and I'm not exactly sure why the
> > usb_put_bus call got moved as well. David, could you explain why that's
> > necessary?
>
> Otherwise devices in this "zombie state" could be used to
> initiate new requests, which would clearly be an error since
> the device is actually gone ... and all of the relevant state
> (except memory for config descriptors and usb_device) has
> been cleaned up.
>
> Remember that there are basically two outcomes at the end of
> usb_disconnect():
>
> - drivers and HCD are all done with the device, so the
> last call in disconnect() will free all the memory.
>
> - OR something has, for some reason, kept a handle to
> that memory, so it'll be freed later.
>
> Breaking that dev->bus linkage when the disconnect is done
> ensures that clean failures will be reported ... and that no new
> HCD state for the device could be created. All the methods
> that go through usb_operations check for null dev->bus.
Good point. One other thing we can also do to ensure that the address
doesn't get reused is to move the call to:
clear_bit(dev->devnum, &dev->bus->devmap.devicemap);
into the code that is executed when the reference count hits 0
(usb_free_dev for 2.4, usb_put_dev for 2.5)
JE
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
