On Mon, 2 Feb 2009, Adam Baker wrote: > What I hadn't noticed before is that usb_buffer_free needs the usb device > pointer and as you say that is no longer valid after gspca_disconnect returns > even if gspca_release hasn't freed the rest of the gspca struct. If that is > the problem then I presume the correct behaviour is for gspca_disconnect to > ensure that all URBs are killed and freed before gspca_disconnect returns. That's right. > This shouldn't be a problem for sq905 (which doesn't use these URBs) or > isochronous cameras (which don't need to resubmit URBs) but the finepix > driver (the other supported bulk device) will need some careful consideration > to avoid a race between killing the URB and resubmitting it. You shouldn't need to take any special action. usb_kill_urb() solves these races for you; it guarantees not to return until the URB has been unlinked and the completion handler has finished, and it guarantees that attempts by the completion handler to resubmit the URB will fail. > Theodore, could you check if adding a call to destroy_urbs() in > gspca_disconnect fixes the crash. (destroy_urbs only frees non NULL urb > pointers so should be safe to call from both disconnect and stream_off, > whichever occurs first). If URBs don't get submitted from anywhere but the completion handler then this will work. However you do have to worry about the race between open and disconnect; you don't want open to start submitting new URBs after disconnect has returned. Many drivers have to worry about this race; usually it is solved by using a private mutex. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
