From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: USB development list <linux-usb-devel@lists.sourceforge.net>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: How should an exit routine wait for release() callbacks?
Date: Fri, 13 Apr 2007 11:03:13 +0200 [thread overview]
Message-ID: <20070413110313.352330ce@gondolin.boeblingen.de.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0704121706040.2472-100000@iolanthe.rowland.org>
On Thu, 12 Apr 2007 17:23:18 -0400 (EDT),
Alan Stern <stern@rowland.harvard.edu> wrote:
> Here's a not-so-theoretical question.
>
> I've got a module which registers a struct device. (It represents a
> virtual device, not a real one, but that doesn't matter.) Obviously the
> module's exit routine has to wait until the release() routine for that
> device has been invoked -- if it returned too early then the release()
> call would oops.
>
> How should it wait?
Device lifetime vs. module lifetime - that's a fun one...
>
> The most straightforward approach is to use a struct completion, like
> this:
>
> static struct {
> struct device dev;
> ...
> } my_dev;
>
> static DECLARE_COMPLETION(my_completion);
>
> static void my_release(struct device *dev)
> {
> complete(&my_completion);
> }
>
> static void __exit my_exit(void)
> {
> device_unregister(&my_dev.dev);
> wait_for_completion(&my_completion);
> }
>
> The problem is that there is no guarantee a context switch won't take
> place after my_release() has called complete() and before my_release()
> returns. If that happens and my_exit() finishes running, then the module
> will be unloaded and the next context switch back to finish off
> my_release() will oops.
>
> Other approaches have similar defects. So how can this problem be solved?
What I see that a device driver may do now is the following:
- disallow module unloading (duh)
- move the release function outside the module
To make the completion approach work, the complete() would need to be
after the release function. This would imply an upper layer, but this
upper layer would need to access the completion structure in the
module...
One could think about a owner field (for getting/putting the module
reference) for the object (with a final module_put() after the release
function has been called). The problem there would be that it would
preclude unloading of the module if there isn't a "self destruct" knob
for the object.
next prev parent reply other threads:[~2007-04-13 9:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-12 21:23 Alan Stern
2007-04-13 9:03 ` Cornelia Huck [this message]
2007-04-13 11:42 ` Markus Rechberger
2007-04-13 13:24 ` Cornelia Huck
2007-04-13 14:15 ` Markus Rechberger
2007-04-13 14:27 ` Cornelia Huck
2007-04-13 15:24 ` Alan Stern
2007-04-16 8:53 ` Cornelia Huck
2007-04-16 14:43 ` Alan Stern
2007-04-16 14:51 ` [linux-usb-devel] " Robert Marquardt
2007-04-16 15:05 ` Cornelia Huck
2007-04-16 22:12 ` [linux-usb-devel] " Greg KH
2007-04-17 7:26 ` Cornelia Huck
2007-04-17 15:59 ` Alan Stern
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=20070413110313.352330ce@gondolin.boeblingen.de.ibm.com \
--to=cornelia.huck@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=stern@rowland.harvard.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome