On Saturday 03 November 2001 3:59 pm, Thomas Sailer wrote: > Duncan Sands wrote: > > races with disconnect. In usb.c there is the usb_disconnect > > function which first calls driver->disconnect, then only later > > Ah ok, you're concerned about the driver ioctl getting called > via usbdevfs. The proc_ioctl interface wasn't added by me, > so I don't know the original intention (Greg K-H? David Brownell?) > > You can probably fairly easily guard against it, since you most likely > have to have a function that takes the usb_device * and finds the > corresponding driver internal state. So the driver needs to have > some list of valid usb_device * and their corresponding internal > state *. If you remove the usb_device * on disconnect from that > table, that mapping function can notice that the device no longer > exists and return an error. > > It's not elegant, though.
No, it's not elegant, but given the situation it seems inevitable. By the way, this seems to me to be a design flaw in the usb subsystem: to illustrate, lets compare with the use of file operations. With file operations, the open and close methods make it easy to deal with this kind of problem: keep a count of how many users have the device open; if no-one has the device open during the disconnect, then just finalize everything. If someone has the device open, then just mark that a disconnect has occurred; when the last user closes the file, finalize everything. So people can happily do ioctl's after the disconnect; the last one to close the device cleans up. With the usb driver ioctl, there are no open/close methods, so you can't do it this way. You are forced to use the ugly method you describe (keep a list of all valid devices). However, the usb subsystem could have been coded so that driver ioctls cannot occur during or after a disconnect (by having a shared lock for example), which would have made this whole problem go away. Wouldn't this be better? Wouldn't this be "the right way" (tm) to do things? And wouldn't it avoid a slew of racy drivers whose author's didn't think about this... > The solution maybe is to call usbdevfs_remove_device earlier... > > > Suppose I do an ioctl via usbdevfs after (or even during) the call to > > during is not a problem. The ioctl will sleep in down_read until > the disconnect is over, then notice that ps->dev is NULL and > return with -ENODEV. Are you sure? Since usbdevfs uses a different semaphore to the one used in usb.c, what is to stop CPU 2 happily doing the ioctl during the disconnect by CPU 1? I don't see any mutual exclusion in the code. Thanks for thinking about this, Duncan. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
