Am Mittwoch, 16. Januar 2008 16:45:19 schrieb Alan Stern:
> On Wed, 16 Jan 2008, Oliver Neukum wrote:
>
> > OK, here's the version without a race against reset.
> >
> > The basic idea is still to use anchor to block submission. So you the
> > disconnect() method can use the anchor to render harmless any code
> > paths using the anchor before submitting.
>
> That's not a bad idea, however I think your implementation does more
> work than really necessary. The whole business of poisoning URBs isn't
> needed; it should be enough to weigh the anchor and kill the existing
> URBs. The fact that the anchor has been weighed will prevent them from
> being resubmitted.
If you use anchors. Drivers that allocate their URBs upon probe() or
open() can benefit from usb_poison_urb().
> Also, changing urb->reject to atomic_t means you can get rid of
> reject_mutex entirely. The only purpose of the mutex was to prevent
> simultaneous non-atomic increments or decrements of urb->reject. (The
> reason for not making it an atomic_t in the first place was simply to
> save space in struct urb.)
OK, I suspected black magic because a spinlock would have done
that job.
> There may be other problems to watch out for. Since you no longer
> synchronize the disconnect routine with URB submission, you run the
> risk of calling usb_submit_urb() after the usb_device structure has
> been deallocated.
Yes. The skeleton driver does the necessary get. Do you see a way
to advance the check of reject without rewriting the entire locking?
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
