From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mikulas Patocka <mpatocka@redhat.com>,
Jeff Mahoney <jeffm@suse.com>,
torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
dm-devel@redhat.com, tglx@linutronix.de,
paulmck@linux.vnet.ibm.com, mingo@kernel.org
Subject: Re: [PATCH] kobject: provide kobject_put_wait to fix module unload race
Date: Sat, 4 Jan 2014 14:42:06 -0800 [thread overview]
Message-ID: <20140104224206.GC18213@core.coreip.homeip.net> (raw)
In-Reply-To: <20140104183403.GG10323@ZenIV.linux.org.uk>
On Sat, Jan 04, 2014 at 06:34:03PM +0000, Al Viro wrote:
> On Sat, Jan 04, 2014 at 10:16:20AM -0800, Greg Kroah-Hartman wrote:
>
> > > I came up with a simpler patch to achieve the same purpose - this patch
> > > makes fixing the drivers easy - the driver is fixed just by replacing
> > > "kobject_put" with "kobject_put_wait" in the unload routine.
> >
> > No, that's not ok at all.
>
> Agreed - all it takes is one cargo-culter who religoiusly does such
> conversion and drops a ref to parent before that to child.
>
> > > However, this pattern is buggy with respect to modules. The release method
> > > is placed in the driver's module. When the driver exits, the module
> > > reference count is zero, thus the module may be freed. However, there may
> > > still be references to the kobject. If the module is unloaded and then the
> > > release method is called, a crash happens.
> >
> > Yes, module unloading while a kobject is still "active" is not a good
> > thing, what modules do you have that cause this problem? Why not just
> > grab the module reference in your kobject if you need this type of
> > protection? It's not the kobject's code fault that this issue is there,
> > or that we now have a "delayed release" function to expose this type of
> > thing, it's the user of the kobject.
> >
> > Please fix the broken users of the kobject first.
>
> <snide> Are you saying that there is another kind? </snide>
>
> When would you grab that reference to module? More to the point, when
> would you *drop* it? Doing so from module_exit is not going to work,
> obviously...
You normally have subsystem core module that does handle release of its
objects and users of said objects so it is usually OK for objects to
outlive the users, you just need to make sure the core stays around.
In input we grab module reference to input core when we allocate input
device and drop it when input device is freed. This way we can be sure
that input core stays around until all input devices are gone. The same
for serio.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2014-01-04 22:42 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-04 18:06 [PATCH] kobject: provide kobject_put_wait to fix module unload race Mikulas Patocka
2014-01-04 18:14 ` Jeff Mahoney
2014-01-05 3:48 ` Greg Kroah-Hartman
2014-01-04 18:16 ` Greg Kroah-Hartman
2014-01-04 18:34 ` Al Viro
2014-01-04 22:42 ` Dmitry Torokhov [this message]
2014-01-05 22:11 ` Mikulas Patocka
2014-01-05 22:39 ` Dmitry Torokhov
2014-01-06 18:43 ` Mikulas Patocka
2014-01-04 20:35 ` Mikulas Patocka
2014-01-05 3:42 ` Greg Kroah-Hartman
2014-01-05 6:05 ` Dmitry Torokhov
2014-01-05 18:27 ` Greg Kroah-Hartman
2014-01-05 22:04 ` Mikulas Patocka
2014-01-05 22:23 ` Greg Kroah-Hartman
2014-01-05 16:43 ` [dm-devel] " Bart Van Assche
2014-01-05 18:26 ` Greg Kroah-Hartman
2014-01-06 18:55 ` Mikulas Patocka
2014-01-06 19:23 ` Greg Kroah-Hartman
2014-01-06 21:31 ` Mike Snitzer
2014-01-07 4:01 ` Mikulas Patocka
2014-01-07 5:25 ` Linus Torvalds
2014-01-07 18:00 ` Mikulas Patocka
2014-01-07 19:19 ` Mike Snitzer
2014-01-07 20:16 ` Mikulas Patocka
2014-01-07 22:32 ` Mike Snitzer
2014-01-07 22:32 ` Mike Snitzer
2014-01-07 14:16 ` Greg Kroah-Hartman
2014-01-07 18:16 ` Mikulas Patocka
2014-01-07 18:26 ` Dmitry Torokhov
2014-01-05 22:04 ` [dm-devel] [PATCH] " Mikulas Patocka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140104224206.GC18213@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=dm-devel@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jeffm@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mpatocka@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.