lkml.org 
[lkml]   [2012]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.



\
 
 \ /
  Last update: 2012-01-10 11:07    [W:0.247 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site