lkml.org 
[lkml]   [2007]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: How should an exit routine wait for release() callbacks?
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




-
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/

\
 
 \ /
  Last update: 2007-04-13 13:53    [W:0.138 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site