Am Samstag, 10. Juni 2006 13:23 schrieb Ulrich Kunitz:
> On 06-06-04 00:25 Oliver Neukum wrote:
>
> > > > +static void disconnect(struct usb_interface *intf)
> > > > This is racy. It allows io to disconnected devices. You must take the
> > > > lock and set a flag that you test after you've taken the lock elsewhere.
> > >
> > > Will fix, thanks.
> >
> > You're welcome
>
> Not so fast, because I don't know what to fix.
>
> Actually there are two cases, when disconnect is called. The first
There are three cases. It can also be triggered by sysfs and usbfs.
> is, when the device is removed. The second is, when the kernel
> module is removed from the kernel. It should also be recognized
> that disconnect() must always succeed, so we have to ignore IO
> errors anyhow.
You can ignore IO errors in disconnect(). They are harmless.
> In the first case we don't need the IO and in the second case we
> have to do it, because otherwise, the device will not come up, if
> we load the driver again.
>
> Testing shows, that doing the IO doesn't create a lot of issues,
> there are some errors reported, but that's it and the second case
> just works fine. So there doesn't appear a problem and even if
> want to be "clean", I would like to know, how to distinguish both
> cases without trying to do IO with the device.
The problem is not that you may do IO _during_ disconnect. You may
do IO _after_ disconnect, even if usbfs might already have claimed
the device. Disconnect() must either terminate ongoing IO or wait for
it to end. And it must make sure that there'll be no IO afterwards.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
