On Thu, Dec 08, 2016 at 12:28:07PM -0800, Kees Cook wrote: > On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > > diff --git a/kernel/kmod.c b/kernel/kmod.c > > index 0277d1216f80..cb6f7ca7b8a5 100644 > > --- a/kernel/kmod.c > > +++ b/kernel/kmod.c > > @@ -44,6 +44,9 @@ > > @@ -186,6 +174,31 @@ int __request_module(bool wait, const char *fmt, ...) > > return ret; > > } > > EXPORT_SYMBOL(__request_module); > > + > > +/* > > + * If modprobe needs a service that is in a module, we get a recursive > > + * loop. Limit the number of running kmod threads to max_threads/2 or > > + * CONFIG_MAX_KMOD_CONCURRENT, whichever is the smaller. A cleaner method > > + * would be to run the parents of this process, counting how many times > > + * kmod was invoked. That would mean accessing the internals of the > > + * process tables to get the command line, proc_pid_cmdline is static > > + * and it is not worth changing the proc code just to handle this case. > > + * > > + * "trace the ppid" is simple, but will fail if someone's > > + * parent exits. I think this is as good as it gets. > > + * > > + * You can override with with a kernel parameter, for instance to allow > > + * 4096 concurrent modprobe instances: > > + * > > + * kmod.max_modprobes=4096 > > + */ > > +void __init init_kmod_umh(void) > > What does umh mean? umh is user mode helper. kmod.c actually implements the kernel's umh code. A subsequent series I will want to move all that to umh.c and keep module loading separate in kmod.c But that's for later as a cleanup. BTW any chance I can have you trim replies to file name and hunk for changes you reply to ? As an example I did that here :) Luis -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
