On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote: > On Wed, Feb 19, 2003 at 05:44:54PM -0500, Johannes Erdfelt wrote: > > On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote: > > > On Wed, Feb 19, 2003 at 02:21:11PM -0800, David Brownell wrote: > > > > Only because you put that check in the unlink path ... I think it'd > > > > be better to mark earlier, and allow cleanup at any time (not check). > > > > > > No, some of the hcds die a horrible death if you try to call unlink on a > > > urb after the device is gone :( > > > > They shouldn't. It should be perfectly valid to do that. > > Hm, uhci-hcd oopses if this happens :) > I could reproduce this very easily without that urb change but with the > usb-serial changes.
Ahh, and that brings us back to the original patch. If so, it could be a bug in uhci-hcd. I'll attempt to duplicate the oops. > > > Sure, fixing up the host controllers would be fine. I wouldn't mind > > > that, and then removing the check on unlink. But I don't think it's a > > > requirement as things seem to work the way they currently are (although > > > I'm waiting for Oliver to find a race somewhere :) > > > > It is racy and should be fixed. > > > > I actually don't have a problem with submitting a request for a device > > that's gone. It'll timeout. Big deal. > > uhci-hcd deadlocks if this happens :) > The traceback had the uhci driver waiting for a timeout somewhere, I > don't remember where, sorry. Hmm, I can't think of any reason why it would deadlock. Does the existing serial driver submit URBs after the device is physically removed? (Like if an application still has an fd open when the device was removed) I'm curious how I could reproduce this. > And what about urbs without timeouts (like bulk reads)? I think it should work and if it doesn't, bugs should be fixed :) > > The HCDs shouldn't be unlinking any URBs (I don't know if that was > > brought up, but has been brought up in the past). The driver that > > submitted the URB should be the only code that unlinks them. > > What happens if the driver doesn't unlink the urb on disconnect, but > only does so a long time after disconnect happens? I image the existing > urb times out, right? Yeah, the HC will return the request back with an error because there is no device to NAK the packet. It will then be returned back to the driver in error via the callback. > > The only problem with it is when you unload the module. The reference > > counting won't handle that. You need to clean up everything outstanding > > immediately, or wait for everything to be cleaned up by some other > > means. > > Or just prevent unloding unless all reference counts are at zero :) Yup, good point. Although, that may piss of the sysadmin. If the device is gone and no applications are using it, the driver should be able to be removed. But this is just a sysadmin user interface thing. > Unfortunatly modules like the keyboard driver don't fit that model > well... Because something is always "using" it? (application or kernel) > > > I'm still thinking through the urb module reference count stuff, and am > > > not entirely convinced that things are currently safe without it, but > > > other things have been distracting me... > > > > The URB reference counting may not be necessary. There's only 2 possible > > pieces of code that can use it: the driver and the HCD. > > > > As long as the rules about who owns the URB when and where are clearly > > defined (and implemented), then reference counting may not be necessary. > > Sure, but even when the HCD "owns" the urb, it can callback into the > driver, and the driver better still be in memory while the urb is alive. Yes, that is a concern, but it's a driver issue. The driver needs to make sure this doesn't happen. > > Look at struct sk_buff for instance, there is no reference count on it. > > Not yet :) Hmm, is there a discussion on linux-kernel that I skipped? JE ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
