On Tue, Feb 26, 2002 at 04:42:09AM -0800, Mark McClelland wrote: > > Ever since I created the ov511-1.49 changeset, I get a revision to my > ChangeSet file whenever I do a pull: > > [EMAIL PROTECTED], 2002-02-25 19:10:39-08:00, [EMAIL PROTECTED] > Merge bk://linuxusb.bkbits.net/usb-2.5 > into hal9000.dyndns.org:/mnt/home2/mark/tmp/bk/usb-2.5 > > Should I be sending them as well? Those are the only other changesets > attributed to myself.
Yes, try sending them all to me. > I tried to see what needed to be sent with "bk send > -ubk://linuxusb.bkbits.net/usb-2.5 - | less" but it didn't work (bk says > "ERROR-BAD CMD: synckeys"). Since I'm not having much luck with bk, I > guess I'll just stick with trusty old diff and patch for now :) Yeah, I could not get that to work either, there's some other way to do it, but I don't remember it now. > Good idea. Since that would change the driver, I'd like to sync the > (2.5) kernel to my latest version before doing this. I assume I should > send you the seven patches that do that separately, versus one big > version 1.49 -> 1.56 patch. Which ever is easier for you to do. Also watch out for the changes in 2.5 that have happened by others outside of the USB group in your driver (memory handling stuff). > I think it's probably safe to replace lock_kernel() with a global > semaphore. There does seem to be a race that I never noticed until now > though. The sequence of events is: > > 1. request_decompressor() is called. > 2. User rmmod's the decompressor, which calls > ov511_deregister_decomp_module() from its __exit function. > 3. request_decompressor() gets the BKL first, and increases the > decompressor's module use count. > 4. ov511_deregister_decomp_module() gets the BKL and completes, and the > decompressor unloads (while it is being used!) > > If a module's use count increases while it is in its __exit function, it > still unloads regardless (it's true; I tested). I guess I need to check > the count in ov511_deregister_decomp_module() and block until it hits zero. > > It seems that this race could foil the protections we use against module > unload races. For example, if a USB driver is in the middle of its > __exit function when a device is plugged in, it doesn't matter whether > the driver's use count is increased before or during probe(); it will > still be unloaded anyway. > > Maybe there's something obvious I'm missing here, though. I should > probably be worrying about ov511's horrible usb_free_urb() SMP races > instead anyway. :) Heh :) Yeah, module unloading races are here to stay until Rusty's 5 stage module loading/unloading patch goes in. Oliver might have some insight in how to do the locking better. And for 2.5, you don't have to worry about any usb_free_urb() races anymore. thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
