Richard Weinberger wrote:
> With MAX_KMOD_CONCURRENT=3 it takes only a few seconds until
> the modprobe storm ends.
OK. Many years ago, I got a few reports that the kernel panics after printing
request_module: runaway loop modprobe binfmt-464c
line. This was because they installed by error a binary x86_32 kernel rpm on
x86_64 userland tools. So, this error is not specific to UML.
> How shall we proceed?
> Applying my ad-hoc patch
> or lowering MAX_KMOD_CONCURRENT?
What about disallowing request_module() for ____call_usermodehelper() threads?
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a837b20..70b52de 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1289,6 +1289,7 @@ struct task_struct {
unsigned did_exec:1;
unsigned in_execve:1; /* Tell the LSMs that the process is doing an
* execve */
+ unsigned no_request_module:1; /* Disallow request_module() calls. */
unsigned in_iowait:1;
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 47613df..32ad87c 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -88,6 +88,8 @@ int __request_module(bool wait, const char *fmt, ...)
#define MAX_KMOD_CONCURRENT 50 /* Completely arbitrary value - KAO */
static int kmod_loop_msg;
+ if (current->no_request_module)
+ return -ENOSYS;
va_start(args, fmt);
ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args);
va_end(args);
@@ -177,6 +179,7 @@ static int ____call_usermodehelper(void *data)
commit_creds(new);
+ current->no_request_module = 1;
retval = kernel_execve(sub_info->path,
(const char *const *)sub_info->argv,
(const char *const *)sub_info->envp);
diff --git a/fs/exec.c b/fs/exec.c
index 6075a1e..b949387 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1387,6 +1387,7 @@ int search_binary_handler(struct linux_binprm *bprm,struct pt_regs *regs)
if (bprm->file)
fput(bprm->file);
bprm->file = NULL;
+ current->no_request_module = 0;
current->did_exec = 1;
proc_exec_connector(current);
return retval;
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
