> > I really doubt that this issue can be not exposed.
>
> And why is that? I just gave you an argument from first
> principles. You can't refute that by pointing to a bug in
Because all the HCD has is a pointer that may or may not be valid.
> one current driver:
> > If I may point you to the following code path:
> > usb_unlink_urb -> sohci_unlink_urb
> > There you find a huge amount of usage of the urb pointer
> > the driver has supplied.
>
> When device drivers call usb_unlink_urb() with a pointer,
> they guarantee that the pointer is valid -- at least, the the
> urb hasn't been freed.
They cannot do that if the completion handler can free the urb.
> While I do see a questionable use there (usb-ohci.c), that's
> also an area that's been cleaned up in the "ohci-hcd" driver.
> (The "ohci-hcd" part just does the hardware bits, while the
> more generic "hcd" part blocks till completion.)
And blocks on what ?
> > Yet usb_unlink_urb and the completion handler can race,
> > at least on SMP. I can see really no way that API is supposed
> > to work if the urb can be freed in the completion handler.
>
> I could see that a driver which frees an urb in its completion
> handler _and_ keeps pointers to those urbs accessible to
> other driver code has a big design bug -- it has no good way
> to know if such pointers are still valid. No SMP needed.
>
> But you seem to be implying more than a bug in the driver
> design, and I can't see that.
David, either you expose this issue or you don't.
If you say that a driver that frees urbs in the completion handler
cannot use usb_unlink_urb(), you do expose it. And you expose it
in a totally unobvious way.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
