Messages in this thread | | | Date | Tue, 10 Jan 2012 11:03:57 +0100 | From | Martin Schwidefsky <> | Subject | Re: Incorrect uses of get_driver()/put_driver() |
| |
On Tue, 10 Jan 2012 01:20:46 -0800 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Tue, Jan 10, 2012 at 10:05:41AM +0100, Martin Schwidefsky wrote: > > On Mon, 9 Jan 2012 12:35:09 -0500 (EST) > > Alan Stern <stern@rowland.harvard.edu> wrote: > > > > > drivers/s390/cio/device.c:1681: drv = get_driver(&cdrv->driver); > > > drivers/s390/cio/device.c:1687: put_driver(drv); > > > > > > Martin, these calls seem to be useless. The calls in ccwgroup.c are > > > definitely useless; there's no reason to take a reference to a driver > > > while it's being unregistered, since it can't go away until the > > > unregistration is finished. > > > > The get_driver/put_driver in ccwgroup.c are obviously useless, the caller > > passed ccwgroup_driver_unregister a ccwgroup_driver reference. > > I am not so sure about the code in device.c. get_ccwdev_by_busid() gets > > used e.g. by vmur like this: > > It does not matter how it is being used. Either get_ccwdev_by_busid() > gets a valid driver structure or you already lost. You can not say that > get_driver() protects anything, since if there is a chance driver can > disappear it can disappear before we get to executing get_driver() code. > > So while you might want to audit callers get/put_driver inside of > get_ccwdev_by_busid() is utterly useless.
Agreed, we have to rely on the module reference counting and the various owner fields to prevent driver unregister while we in a code path that might call get_ccwdev_by_busid(). Lets keep our fingers crossed that all owner fields are set correctly.
-- blue skies, Martin.
"Reality continues to ruin my life." - Calvin.
| |