On Friday 10 January 2003 14:55, Oliver Neukum wrote:
> Am Freitag, 10. Januar 2003 13:21 schrieb Duncan Sands:
> > > I am afraid I do not agree. Your reasoning is correct only on UP.
> > > If the code in question runs on another CPU, you are in trouble.
> >
> > It all depends on the semantics of usb_unlink_urb. Consider the
> > patch below. Is this any better? Maybe not: if usb_unlink_urb
> > returns before the completion handler (running on another CPU)
> > reaches the tasklet_schedule statement, then what is to stop
> > the tasklet being scheduled by the completion handler after the
> > tasklet_kill? Nothing. So it all depends on whether or
> > not usb_unlink_urb guarantees that the completion handler has
> > finished running before it (usb_unlink_urb) returns.
>
> if (urb->status != -EINPROGRESS) {
> retval = -EBUSY;
> goto done;
> }
> from hcd.c
>
> So, usb_unlink_urb() will explicitely return if the completion handler
> is running. To be safe you need something like:
>
> (in disconnect() )
> spin_lock_irq(...);
> descriptor->disconnected = 1;
> tasklet_kill(...);
> spin_unlock_irq(...);
>
> (in the completion handler)
> spin_lock(...);
> if (!descriptor->disconnected)
> tasklet_schedule(...);
> spin_unlock(...);
Hi Oliver, thanks for the suggestion. It is not quite so simple because you also
have to deal with the private data ("instance") being kfreed soon afterwards (see
udsl_usb_disconnect). Anyway, I will take care of it.
Ciao, Duncan.
PS: I won't be around until the end of next week, so don't expect a patch before then.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
