lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 13 Apr 2007 13:42:04 +0200 From: "Markus Rechberger" <markus.rechberger@....com> To: "Cornelia Huck" <cornelia.huck@...ibm.com> cc: "Alan Stern" <stern@...land.harvard.edu>, "USB development list" <linux-usb-devel@...ts.sourceforge.net>, "Kernel development list" <linux-kernel@...r.kernel.org> Subject: Re: 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@...land.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@...r.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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists