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

["Markus Rechberger" <markus.rechberger@amd.com>]

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 <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.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> 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