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: Thu, 21 Feb 2008 17:47:12 -0800 From: Max Krasnyanskiy <maxk@...lcomm.com> To: Tejun Heo <htejun@...il.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" Tejun Heo wrote: > 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. static struct module *load_module(void __user *umod, unsigned long len, const char __user *uargs) { ... /* Now sew it into the lists so we can get lockdep and oops * info during argument parsing. Noone should access us, since * strong_try_module_get() will fail. */ stop_machine_run(__link_module, mod, NR_CPUS); ... } I actually rarely unload modules. The way I notice the problem in first place is when things started hanging when tun driver was autoloaded or when fs automounts triggered some auto loading. These days it's kind hard to have a semi-general purpose machine without module loading :). Max -- 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