> Yes it does. But completion routines get called at interrupt time.
> However, this is not really relevant to the problem at hand.
For these cases we need a spinlock, yes.
> > > case it doesn't matter, since we only want to guarantee that no URB
> > > will be submitted after disconnect() _returns_. We don't need to (and
> > > in fact cannot) guarantee that no URB will be submitted after
> > > disconnect() _is called_.
> >
> > Right. But why should this matter? If there's a race there's a race.
> > Unless you can guarantee that disconnect() setting a flag for
> > disconnection and an urb being submitted or a synchronous helper running
> > don't race it's a bug.
>
> That's not necessarily true. There are plenty of examples where races are
> not bugs. (There's even one in usb-storage.) It's just a question of
> writing the code so that no matter who wins the race, it does the right
> thing.
OK.
> > > Perhaps the real question is: Do we need to guarantee that no URBs will
> > > remain outstanding after disconnect() returns? This seems to be what
> > > you
> >
> > if (!(dev = urb->dev) || !dev->bus || dev->devnum <= 0)
> > return -ENODEV;
> > if (!(op = dev->bus->op) || !op->submit_urb)
> > return -ENODEV;
> >
> > from usb_submit_urb(). This is deadly. Unlinking after disconnect() is
> > deadly as well.
> > But for an indeterminate amount of time after usb_submit_urb is called,
> > it's dangerous. Shortly, it's safe only if they are dead.
>
> I don't understand what you have written here. Regardless of that, I
> gather from what you say elsewhere that we need to guarantee that after
> disconnect() returns, there are no URBs still in progress and no new URBs
> are submitted.
I've not actually verified that a linked urb after disconnect is evil.
But I am sure that doing the unlink after disconnect and being in
usb_submit_urb() after disconnect is potentially deadly.
Interestingly even a read following a pointer to freed memory can lead
to data corruption.
But as you cannot tell whether you are about to call usb_submit_urb(),
are executing it or have just left it, it makes no difference to locking.
> If that's so, then there is nothing to worry about as far as usb-storage
> is concerned. There already is a semaphore that protects against exactly
> this sort of thing. You didn't see it in usb_stor_clear_halt and
> usb_stor_reset_common because it is tested higher up in the code chain.
> For instance, look at device_reset() in scsiglue.c; you'll see a line that
> does
Good, then I'll go through the next driver.
It's important that people become aware of this issue.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
