Re: How should an exit routine wait for release() callbacks?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alan,

seems like you have the same problem as the dvb framework has/had.

http://mcentral.de/hg/~mrec/v4l-dvb-stable

The last 3 changesets do the trick to not oops, it will delay the deinitialization of the device till the last user closed the device node.

Markus

Cornelia Huck wrote:
On Thu, 12 Apr 2007 17:23:18 -0400 (EDT),
Alan Stern <[email protected]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/






--
          |           AMD Saxony Limited Liability Company & Co. KG
Operating |         Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System   |                  Register Court Dresden: HRA 4896
Research  |              General Partner authorized to represent:
 Center   |             AMD Saxony LLC (Wilmington, Delaware, US)
          | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux