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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
