On Sunday 08 December 2002 16:05, Oliver Neukum wrote: > Am Sonntag, 8. Dezember 2002 07:18 schrieb Duncan Sands: > > > disconnect and usbdev_open do locking with BKL. > > > usbdev_open allocates memory. That may drop BKL. > > > Thus memory allocation must be done before the > > > device is checked for validity. Change set included. > > > Note: my kernel currently refuses to compile > > > due to pci_quirks, thus it's untested. > > > Comments ? > > > > Why not get rid of the BKL altogether? > > What should replace it and where's the benefit ?
It could (nearly) be replaced with nothing at all. There is little benefit though. In usbdev_open, the BKL is only being used to protect dev->filelist, even if at first it seems that it is protecting against a race with disconnect - namely the possibility of dev being changed to null under you. Why is there no race with disconnect? Because the disconnect code holds the BKL and usbdev_open does not sleep (after the kmalloc at least; good catch by the way). So the value of dev does not change. So what is the BKL being used for? As far as I can see it is being used to serialize access to dev->filelist and that is all. Usually a spin lock is used for such tasks, but hey! this is not a critical code path. Ciao, Duncan. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
