| 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
| ||
|
Message-ID: <47BE27AE.8050009@gmail.com> Date: Fri, 22 Feb 2008 10:38:54 +0900 From: Tejun Heo <htejun@...il.com> To: Max Krasnyanskiy <maxk@...lcomm.com> CC: rusty@...tcorp.com.au, Andrew Morton <akpm@...ux-foundation.org>, LKML <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: Module loading/unloading and "The Stop Machine" Max Krasnyanskiy wrote: > Thanks for the info. I guess I missed that from the code. In any case > that seems like a pretty heavy refcounting mechanism. In a sense that > every time something is loaded or unloaded entire machine freezes, > potentially for several milliseconds. Normally it's not a big deal. But > once you get more and more CPUs and/or start using realtime apps this > becomes a big deal. Module loading doesn't involve stop_machine last time I checked. It's a big deal when unloading a module but it's actually a very good trade off because it makes much hotter path (module_get/put) much cheaper. If your application can't stand stop_machine, simply don't unload a module. > And it's plain broken for the use case that I mentioned > during CPU isolation discussions. ie When user-space thread(s) prevent > stopmachine kthread from running, in which > case machine simply hangs until those user-space threads exit. This I don't know nothing about. :-) -- tejun -- 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