[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161208210039.GY1402@wotan.suse.de>
Date: Thu, 8 Dec 2016 22:00:40 +0100
From: "Luis R. Rodriguez" <mcgrof@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: "Luis R. Rodriguez" <mcgrof@...nel.org>, shuah@...nel.org,
Jessica Yu <jeyu@...hat.com>,
Rusty Russell <rusty@...tcorp.com.au>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Jonathan Corbet <corbet@....net>, martin.wilck@...e.com,
Michal Marek <mmarek@...e.com>, Petr Mladek <pmladek@...e.com>,
hare@...e.com, rwright@....com, Jeff Mahoney <jeffm@...e.com>,
DSterba@...e.com, fdmanana@...e.com, neilb@...e.com,
Guenter Roeck <linux@...ck-us.net>, rgoldwyn@...e.com,
subashab@...eaurora.org, Heinrich Schuchardt <xypron.glpk@....de>,
Aaron Tomlin <atomlin@...hat.com>, mbenes@...e.cz,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Dan Williams <dan.j.williams@...el.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
"David S. Miller" <davem@...emloft.net>,
Ingo Molnar <mingo@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kselftest@...r.kernel.org,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 03/10] kmod: add dynamic max concurrent thread count
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@...nel.org> 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
Powered by blists - more mailing lists