On Fri, Dec 16, 2016 at 09:39:56AM +0100, Luis R. Rodriguez wrote: > On Wed, Dec 14, 2016 at 04:38:27PM +0100, Petr Mladek wrote: > > On Thu 2016-12-08 11:48:14, Luis R. Rodriguez wrote: > > > diff --git a/init/Kconfig b/init/Kconfig > > > index 271692a352f1..da2c25746937 100644 > > > --- a/init/Kconfig > > > +++ b/init/Kconfig > > > @@ -2111,6 +2111,29 @@ config TRIM_UNUSED_KSYMS > > > > > > If unsure, or if you need to build out-of-tree modules, say N. > > > > > > +config MAX_KMOD_CONCURRENT > > > + int "Max allowed concurrent request_module() calls (6=>64, 10=>1024)" > > > + range 0 14 > > > > Would not too small range break loading module dependencies? > > No, dependencies are resolved by depmod, so userspace looks at the list and > just finit_module() the depenencies, skipping kmod. So the limit is > really only for kernel acting like a boss. > > > I am not sure how it is implemented but it might require having > > some more module loads in progress. > > Dependencies should be OK, a more serious concern with dependencies is > the aggregate memory it takes to load all dep modules for one required > module since finit_module() ends up allocating the struct module to copy > over data from userspace. A simple change can enable us to bail out on finit_module() if a module is already present by looking at the passed userspace data. I have this change now but as discussed, whether or not its desirable should be a matter of whether or not in the typical case (bootup time) things improve. >From some initial tests it would seem this doesn't help much but it does help with trying to load the same module over and over again, the explanation I can think of for this is by introducing a lookup on finit_module() we also delay module loading by the lookup time, in the general case we would not need this, so this is likely not worth merging. Will run some final tests to confirm. 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
