Messages in this thread | | | Date | Mon, 9 Jan 2012 13:34:14 -0500 | From | Konrad Rzeszutek Wilk <> | Subject | Re: Incorrect uses of get_driver()/put_driver() |
| |
On Mon, Jan 09, 2012 at 10:20:45AM -0800, Dmitry Torokhov wrote: > On Mon, Jan 09, 2012 at 12:48:36PM -0500, Konrad Rzeszutek Wilk wrote: > > On Mon, Jan 09, 2012 at 12:35:09PM -0500, Alan Stern wrote: > > > The get_driver() and put_driver() routines in the device core are not > > > documented well, and what they really do is quite different from what > > > people might think they do. In particular, get_driver() does not > > > prevent a driver from being unregistered or unloaded -- the API which > > > comes closest to doing that is try_module_get(). > > > > > > In fact, get_driver() and put_driver() are pretty much useless for > > > normal purposes, and Dmitry and I have been discussing getting rid of > > > them entirely. But first we need to make sure that doing so won't mess > > > anything up. > > > > > > The purpose of this email is to check with the maintainers of the > > > various drivers that seem to be using these routines in questionable > > > ways, to make sure nothing will go wrong. Here are the places we have > > > identified: > > > > > > lib/dma-debug.c:173: drv = get_driver(dev->driver); > > > lib/dma-debug.c:188: put_driver(drv); > > > > > > Joerg, these calls don't seem to do anything, as far as I can tell. > > > Is there any reason to keep them? > > > > > > drivers/pci/xen-pcifront.c:596: if (get_driver(&pdrv->driver)) { > > > drivers/pci/xen-pcifront.c:626: put_driver(&pdrv->driver); > > > > > > Konrad, these calls don't seem to do anything either. > > > > > > > Looks like they should be replaced with the try_module_get() equivalant > > for the 'struct pci_driver'? Is there such one? > > You seem to need stronger guarantees that the driver simply present in > memory. You need to make sure that the driver you fetched is kept being > bound to the device for entire duration of pcifront_common_process().
OK, any suggestions?
| |