> > No, the real simple solution here would be to state that an urb that has
> > been passed to a completion handler is referenced and must not be freed,
> > not even by the complition handler itself.
>
> Are you aware of how much you're contradicting yourself?
As I said a little further down, I consider it referenced twice.
What is referenced twice, nobody holding the reference once
only may free it.
> If it's a pure refcount scheme, then a completion handler _could_ very
> reasonably decrement the count to zero -- causing a kfree.
Only by a bug, as it has only one of two references.
> > In the literal sense there are two references to that urb.
> > One is held by the complition handler/usbcore
>
> Let's see, completion handler == driver, usbcore == not driver.
> So which is it? I'd say "driver" ...
The completion handler is in this sense part of the usbcore.
The usbcore may need the urb again after the completion
handler has returned. Calling usb_unlink_urb() while the completion
handler is legal and must remain legal, as even if it is spinning on
a lock it is executing. Yet you need a valid pointer to an urb
to be able to unlink it, because you must pass the completion handler
an urb.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
