2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
kmod, the new module loader (replaces kerneld)
|
|
|
|
Kirk Petersen
|
|
|
|
|
|
|
|
Reorganized not to be a daemon by Adam Richter, with guidance
|
|
|
|
from Greg Zornetzer.
|
|
|
|
|
|
|
|
Modified to avoid chroot and file sharing problems.
|
|
|
|
Mikael Pettersson
|
|
|
|
|
|
|
|
Limit the concurrent number of kmod modprobes to catch loops from
|
|
|
|
"modprobe needs a service that is in a module".
|
|
|
|
Keith Owens <kaos@ocs.com.au> December 1999
|
|
|
|
|
|
|
|
Unblock all signals when we exec a usermode process.
|
|
|
|
Shuu Yamaguchi <shuu@wondernetworkresources.com> December 2000
|
|
|
|
|
|
|
|
call_usermodehelper wait flag, and remove exec_usermodehelper.
|
|
|
|
Rusty Russell <rusty@rustcorp.com.au> Jan 2003
|
|
|
|
*/
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/syscalls.h>
|
|
|
|
#include <linux/unistd.h>
|
|
|
|
#include <linux/kmod.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/completion.h>
|
2011-04-01 15:07:50 -06:00
|
|
|
#include <linux/cred.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <linux/file.h>
|
2008-04-24 05:44:08 -06:00
|
|
|
#include <linux/fdtable.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <linux/workqueue.h>
|
|
|
|
#include <linux/security.h>
|
|
|
|
#include <linux/mount.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/init.h>
|
2006-10-01 00:29:28 -06:00
|
|
|
#include <linux/resource.h>
|
2007-07-19 02:47:36 -06:00
|
|
|
#include <linux/notifier.h>
|
|
|
|
#include <linux/suspend.h>
|
PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.
However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:
...
if (usermodehelper_is_disabled())
goto out;
/* Do actual work */
...
out:
return err;
Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.
In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.
Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
This patch adds proper synchronization to fix this issue.
It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09 15:36:36 -07:00
|
|
|
#include <linux/rwsem.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <asm/uaccess.h>
|
|
|
|
|
2009-08-17 02:56:28 -06:00
|
|
|
#include <trace/events/module.h>
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
extern int max_threads;
|
|
|
|
|
|
|
|
static struct workqueue_struct *khelper_wq;
|
|
|
|
|
2011-04-01 15:07:50 -06:00
|
|
|
#define CAP_BSET (void *)1
|
|
|
|
#define CAP_PI (void *)2
|
|
|
|
|
|
|
|
static kernel_cap_t usermodehelper_bset = CAP_FULL_SET;
|
|
|
|
static kernel_cap_t usermodehelper_inheritable = CAP_FULL_SET;
|
|
|
|
static DEFINE_SPINLOCK(umh_sysctl_lock);
|
PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.
However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:
...
if (usermodehelper_is_disabled())
goto out;
/* Do actual work */
...
out:
return err;
Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.
In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.
Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
This patch adds proper synchronization to fix this issue.
It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09 15:36:36 -07:00
|
|
|
static DECLARE_RWSEM(umhelper_sem);
|
2011-04-01 15:07:50 -06:00
|
|
|
|
2008-07-08 11:00:17 -06:00
|
|
|
#ifdef CONFIG_MODULES
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
modprobe_path is set via /proc/sys.
|
|
|
|
*/
|
|
|
|
char modprobe_path[KMOD_PATH_LEN] = "/sbin/modprobe";
|
|
|
|
|
2012-03-23 16:02:50 -06:00
|
|
|
static void free_modprobe_argv(struct subprocess_info *info)
|
|
|
|
{
|
|
|
|
kfree(info->argv[3]); /* check call_modprobe() */
|
|
|
|
kfree(info->argv);
|
|
|
|
}
|
|
|
|
|
2012-03-23 16:02:49 -06:00
|
|
|
static int call_modprobe(char *module_name, int wait)
|
|
|
|
{
|
|
|
|
static char *envp[] = {
|
|
|
|
"HOME=/",
|
|
|
|
"TERM=linux",
|
|
|
|
"PATH=/sbin:/usr/sbin:/bin:/usr/bin",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2012-03-23 16:02:50 -06:00
|
|
|
char **argv = kmalloc(sizeof(char *[5]), GFP_KERNEL);
|
|
|
|
if (!argv)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
module_name = kstrdup(module_name, GFP_KERNEL);
|
|
|
|
if (!module_name)
|
|
|
|
goto free_argv;
|
|
|
|
|
|
|
|
argv[0] = modprobe_path;
|
|
|
|
argv[1] = "-q";
|
|
|
|
argv[2] = "--";
|
|
|
|
argv[3] = module_name; /* check free_modprobe_argv() */
|
|
|
|
argv[4] = NULL;
|
2012-03-23 16:02:49 -06:00
|
|
|
|
|
|
|
return call_usermodehelper_fns(modprobe_path, argv, envp,
|
2012-03-23 16:02:50 -06:00
|
|
|
wait | UMH_KILLABLE, NULL, free_modprobe_argv, NULL);
|
|
|
|
free_argv:
|
|
|
|
kfree(argv);
|
|
|
|
out:
|
|
|
|
return -ENOMEM;
|
2012-03-23 16:02:49 -06:00
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/**
|
2009-02-08 11:42:01 -07:00
|
|
|
* __request_module - try to load a kernel module
|
|
|
|
* @wait: wait (or not) for the operation to complete
|
2009-01-06 15:42:39 -07:00
|
|
|
* @fmt: printf style format string for the name of the module
|
|
|
|
* @...: arguments as specified in the format string
|
2005-04-16 16:20:36 -06:00
|
|
|
*
|
|
|
|
* Load a module using the user mode module loader. The function returns
|
|
|
|
* zero on success or a negative errno code on failure. Note that a
|
|
|
|
* successful module load does not mean the module did not then unload
|
|
|
|
* and exit on an error of its own. Callers must check that the service
|
|
|
|
* they requested is now available not blindly invoke it.
|
|
|
|
*
|
|
|
|
* If module auto-loading support is disabled then this function
|
|
|
|
* becomes a no-operation.
|
|
|
|
*/
|
2009-02-08 11:42:01 -07:00
|
|
|
int __request_module(bool wait, const char *fmt, ...)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
va_list args;
|
|
|
|
char module_name[MODULE_NAME_LEN];
|
|
|
|
unsigned int max_modprobes;
|
|
|
|
int ret;
|
|
|
|
static atomic_t kmod_concurrent = ATOMIC_INIT(0);
|
|
|
|
#define MAX_KMOD_CONCURRENT 50 /* Completely arbitrary value - KAO */
|
|
|
|
static int kmod_loop_msg;
|
|
|
|
|
|
|
|
va_start(args, fmt);
|
|
|
|
ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args);
|
|
|
|
va_end(args);
|
|
|
|
if (ret >= MODULE_NAME_LEN)
|
|
|
|
return -ENAMETOOLONG;
|
|
|
|
|
2009-11-02 22:35:32 -07:00
|
|
|
ret = security_kernel_module_request(module_name);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/* 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
|
|
|
|
* 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.
|
|
|
|
* KAO.
|
|
|
|
*
|
|
|
|
* "trace the ppid" is simple, but will fail if someone's
|
|
|
|
* parent exits. I think this is as good as it gets. --RR
|
|
|
|
*/
|
|
|
|
max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT);
|
|
|
|
atomic_inc(&kmod_concurrent);
|
|
|
|
if (atomic_read(&kmod_concurrent) > max_modprobes) {
|
|
|
|
/* We may be blaming an innocent here, but unlikely */
|
2011-10-25 20:40:39 -06:00
|
|
|
if (kmod_loop_msg < 5) {
|
2005-04-16 16:20:36 -06:00
|
|
|
printk(KERN_ERR
|
|
|
|
"request_module: runaway loop modprobe %s\n",
|
|
|
|
module_name);
|
2011-10-25 20:40:39 -06:00
|
|
|
kmod_loop_msg++;
|
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
atomic_dec(&kmod_concurrent);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2009-08-17 02:56:28 -06:00
|
|
|
trace_module_request(module_name, wait, _RET_IP_);
|
|
|
|
|
2012-03-23 16:02:49 -06:00
|
|
|
ret = call_modprobe(module_name, wait ? UMH_WAIT_PROC : UMH_WAIT_EXEC);
|
kmod: add init function to usermodehelper
About 6 months ago, I made a set of changes to how the core-dump-to-a-pipe
feature in the kernel works. We had reports of several races, including
some reports of apps bypassing our recursion check so that a process that
was forked as part of a core_pattern setup could infinitely crash and
refork until the system crashed.
We fixed those by improving our recursion checks. The new check basically
refuses to fork a process if its core limit is zero, which works well.
Unfortunately, I've been getting grief from maintainer of user space
programs that are inserted as the forked process of core_pattern. They
contend that in order for their programs (such as abrt and apport) to
work, all the running processes in a system must have their core limits
set to a non-zero value, to which I say 'yes'. I did this by design, and
think thats the right way to do things.
But I've been asked to ease this burden on user space enough times that I
thought I would take a look at it. The first suggestion was to make the
recursion check fail on a non-zero 'special' number, like one. That way
the core collector process could set its core size ulimit to 1, and enable
the kernel's recursion detection. This isn't a bad idea on the surface,
but I don't like it since its opt-in, in that if a program like abrt or
apport has a bug and fails to set such a core limit, we're left with a
recursively crashing system again.
So I've come up with this. What I've done is modify the
call_usermodehelper api such that an extra parameter is added, a function
pointer which will be called by the user helper task, after it forks, but
before it exec's the required process. This will give the caller the
opportunity to get a call back in the processes context, allowing it to do
whatever it needs to to the process in the kernel prior to exec-ing the
user space code. In the case of do_coredump, this callback is ues to set
the core ulimit of the helper process to 1. This elimnates the opt-in
problem that I had above, as it allows the ulimit for core sizes to be set
to the value of 1, which is what the recursion check looks for in
do_coredump.
This patch:
Create new function call_usermodehelper_fns() and allow it to assign both
an init and cleanup function, as we'll as arbitrary data.
The init function is called from the context of the forked process and
allows for customization of the helper process prior to calling exec. Its
return code gates the continuation of the process, or causes its exit.
Also add an arbitrary data pointer to the subprocess_info struct allowing
for data to be passed from the caller to the new process, and the
subsequent cleanup process
Also, use this patch to cleanup the cleanup function. It currently takes
an argp and envp pointer for freeing, which is ugly. Lets instead just
make the subprocess_info structure public, and pass that to the cleanup
and init routines
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-26 15:42:58 -06:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
atomic_dec(&kmod_concurrent);
|
|
|
|
return ret;
|
|
|
|
}
|
2009-02-08 11:42:01 -07:00
|
|
|
EXPORT_SYMBOL(__request_module);
|
2008-10-17 01:38:36 -06:00
|
|
|
#endif /* CONFIG_MODULES */
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This is the task which runs the usermode application
|
|
|
|
*/
|
|
|
|
static int ____call_usermodehelper(void *data)
|
|
|
|
{
|
|
|
|
struct subprocess_info *sub_info = data;
|
2011-04-01 15:07:50 -06:00
|
|
|
struct cred *new;
|
2005-04-16 16:20:36 -06:00
|
|
|
int retval;
|
|
|
|
|
|
|
|
spin_lock_irq(¤t->sighand->siglock);
|
|
|
|
flush_signal_handlers(current, 1);
|
|
|
|
spin_unlock_irq(¤t->sighand->siglock);
|
|
|
|
|
|
|
|
/* We can run anywhere, unlike our parent keventd(). */
|
2009-03-30 22:05:10 -06:00
|
|
|
set_cpus_allowed_ptr(current, cpu_all_mask);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2007-05-08 01:28:24 -06:00
|
|
|
/*
|
|
|
|
* Our parent is keventd, which runs with elevated scheduling priority.
|
|
|
|
* Avoid propagating that into the userspace child.
|
|
|
|
*/
|
|
|
|
set_user_nice(current, 0);
|
|
|
|
|
2011-04-01 15:07:50 -06:00
|
|
|
retval = -ENOMEM;
|
|
|
|
new = prepare_kernel_cred(current);
|
|
|
|
if (!new)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
spin_lock(&umh_sysctl_lock);
|
|
|
|
new->cap_bset = cap_intersect(usermodehelper_bset, new->cap_bset);
|
|
|
|
new->cap_inheritable = cap_intersect(usermodehelper_inheritable,
|
|
|
|
new->cap_inheritable);
|
|
|
|
spin_unlock(&umh_sysctl_lock);
|
|
|
|
|
2011-06-17 04:25:59 -06:00
|
|
|
if (sub_info->init) {
|
|
|
|
retval = sub_info->init(sub_info, new);
|
|
|
|
if (retval) {
|
|
|
|
abort_creds(new);
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-01 15:07:50 -06:00
|
|
|
commit_creds(new);
|
|
|
|
|
2010-08-17 16:52:56 -06:00
|
|
|
retval = kernel_execve(sub_info->path,
|
|
|
|
(const char *const *)sub_info->argv,
|
|
|
|
(const char *const *)sub_info->envp);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* Exec failed? */
|
kmod: add init function to usermodehelper
About 6 months ago, I made a set of changes to how the core-dump-to-a-pipe
feature in the kernel works. We had reports of several races, including
some reports of apps bypassing our recursion check so that a process that
was forked as part of a core_pattern setup could infinitely crash and
refork until the system crashed.
We fixed those by improving our recursion checks. The new check basically
refuses to fork a process if its core limit is zero, which works well.
Unfortunately, I've been getting grief from maintainer of user space
programs that are inserted as the forked process of core_pattern. They
contend that in order for their programs (such as abrt and apport) to
work, all the running processes in a system must have their core limits
set to a non-zero value, to which I say 'yes'. I did this by design, and
think thats the right way to do things.
But I've been asked to ease this burden on user space enough times that I
thought I would take a look at it. The first suggestion was to make the
recursion check fail on a non-zero 'special' number, like one. That way
the core collector process could set its core size ulimit to 1, and enable
the kernel's recursion detection. This isn't a bad idea on the surface,
but I don't like it since its opt-in, in that if a program like abrt or
apport has a bug and fails to set such a core limit, we're left with a
recursively crashing system again.
So I've come up with this. What I've done is modify the
call_usermodehelper api such that an extra parameter is added, a function
pointer which will be called by the user helper task, after it forks, but
before it exec's the required process. This will give the caller the
opportunity to get a call back in the processes context, allowing it to do
whatever it needs to to the process in the kernel prior to exec-ing the
user space code. In the case of do_coredump, this callback is ues to set
the core ulimit of the helper process to 1. This elimnates the opt-in
problem that I had above, as it allows the ulimit for core sizes to be set
to the value of 1, which is what the recursion check looks for in
do_coredump.
This patch:
Create new function call_usermodehelper_fns() and allow it to assign both
an init and cleanup function, as we'll as arbitrary data.
The init function is called from the context of the forked process and
allows for customization of the helper process prior to calling exec. Its
return code gates the continuation of the process, or causes its exit.
Also add an arbitrary data pointer to the subprocess_info struct allowing
for data to be passed from the caller to the new process, and the
subsequent cleanup process
Also, use this patch to cleanup the cleanup function. It currently takes
an argp and envp pointer for freeing, which is ugly. Lets instead just
make the subprocess_info structure public, and pass that to the cleanup
and init routines
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-26 15:42:58 -06:00
|
|
|
fail:
|
2005-04-16 16:20:36 -06:00
|
|
|
sub_info->retval = retval;
|
2012-03-23 16:02:49 -06:00
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2007-07-17 19:37:02 -06:00
|
|
|
void call_usermodehelper_freeinfo(struct subprocess_info *info)
|
|
|
|
{
|
|
|
|
if (info->cleanup)
|
kmod: add init function to usermodehelper
About 6 months ago, I made a set of changes to how the core-dump-to-a-pipe
feature in the kernel works. We had reports of several races, including
some reports of apps bypassing our recursion check so that a process that
was forked as part of a core_pattern setup could infinitely crash and
refork until the system crashed.
We fixed those by improving our recursion checks. The new check basically
refuses to fork a process if its core limit is zero, which works well.
Unfortunately, I've been getting grief from maintainer of user space
programs that are inserted as the forked process of core_pattern. They
contend that in order for their programs (such as abrt and apport) to
work, all the running processes in a system must have their core limits
set to a non-zero value, to which I say 'yes'. I did this by design, and
think thats the right way to do things.
But I've been asked to ease this burden on user space enough times that I
thought I would take a look at it. The first suggestion was to make the
recursion check fail on a non-zero 'special' number, like one. That way
the core collector process could set its core size ulimit to 1, and enable
the kernel's recursion detection. This isn't a bad idea on the surface,
but I don't like it since its opt-in, in that if a program like abrt or
apport has a bug and fails to set such a core limit, we're left with a
recursively crashing system again.
So I've come up with this. What I've done is modify the
call_usermodehelper api such that an extra parameter is added, a function
pointer which will be called by the user helper task, after it forks, but
before it exec's the required process. This will give the caller the
opportunity to get a call back in the processes context, allowing it to do
whatever it needs to to the process in the kernel prior to exec-ing the
user space code. In the case of do_coredump, this callback is ues to set
the core ulimit of the helper process to 1. This elimnates the opt-in
problem that I had above, as it allows the ulimit for core sizes to be set
to the value of 1, which is what the recursion check looks for in
do_coredump.
This patch:
Create new function call_usermodehelper_fns() and allow it to assign both
an init and cleanup function, as we'll as arbitrary data.
The init function is called from the context of the forked process and
allows for customization of the helper process prior to calling exec. Its
return code gates the continuation of the process, or causes its exit.
Also add an arbitrary data pointer to the subprocess_info struct allowing
for data to be passed from the caller to the new process, and the
subsequent cleanup process
Also, use this patch to cleanup the cleanup function. It currently takes
an argp and envp pointer for freeing, which is ugly. Lets instead just
make the subprocess_info structure public, and pass that to the cleanup
and init routines
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-26 15:42:58 -06:00
|
|
|
(*info->cleanup)(info);
|
2007-07-17 19:37:02 -06:00
|
|
|
kfree(info);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(call_usermodehelper_freeinfo);
|
|
|
|
|
2012-03-23 16:02:47 -06:00
|
|
|
static void umh_complete(struct subprocess_info *sub_info)
|
|
|
|
{
|
2012-03-23 16:02:47 -06:00
|
|
|
struct completion *comp = xchg(&sub_info->complete, NULL);
|
|
|
|
/*
|
|
|
|
* See call_usermodehelper_exec(). If xchg() returns NULL
|
|
|
|
* we own sub_info, the UMH_KILLABLE caller has gone away.
|
|
|
|
*/
|
|
|
|
if (comp)
|
|
|
|
complete(comp);
|
|
|
|
else
|
|
|
|
call_usermodehelper_freeinfo(sub_info);
|
2012-03-23 16:02:47 -06:00
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/* Keventd can't block, but this (a child) can. */
|
|
|
|
static int wait_for_helper(void *data)
|
|
|
|
{
|
|
|
|
struct subprocess_info *sub_info = data;
|
|
|
|
pid_t pid;
|
|
|
|
|
2010-05-26 15:43:03 -06:00
|
|
|
/* If SIGCLD is ignored sys_wait4 won't populate the status. */
|
|
|
|
spin_lock_irq(¤t->sighand->siglock);
|
|
|
|
current->sighand->action[SIGCHLD-1].sa.sa_handler = SIG_DFL;
|
|
|
|
spin_unlock_irq(¤t->sighand->siglock);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
pid = kernel_thread(____call_usermodehelper, sub_info, SIGCHLD);
|
|
|
|
if (pid < 0) {
|
|
|
|
sub_info->retval = pid;
|
|
|
|
} else {
|
2010-05-26 15:43:03 -06:00
|
|
|
int ret = -ECHILD;
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* Normally it is bogus to call wait4() from in-kernel because
|
|
|
|
* wait4() wants to write the exit code to a userspace address.
|
|
|
|
* But wait_for_helper() always runs as keventd, and put_user()
|
|
|
|
* to a kernel address works OK for kernel threads, due to their
|
|
|
|
* having an mm_segment_t which spans the entire address space.
|
|
|
|
*
|
|
|
|
* Thus the __user pointer cast is valid here.
|
|
|
|
*/
|
2006-09-29 03:00:46 -06:00
|
|
|
sys_wait4(pid, (int __user *)&ret, 0, NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If ret is 0, either ____call_usermodehelper failed and the
|
|
|
|
* real error code is already in sub_info->retval or
|
|
|
|
* sub_info->retval is 0 anyway, so don't mess with it then.
|
|
|
|
*/
|
|
|
|
if (ret)
|
|
|
|
sub_info->retval = ret;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2012-03-23 16:02:47 -06:00
|
|
|
umh_complete(sub_info);
|
2005-04-16 16:20:36 -06:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This is run by khelper thread */
|
2006-11-22 07:55:48 -07:00
|
|
|
static void __call_usermodehelper(struct work_struct *work)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2006-11-22 07:55:48 -07:00
|
|
|
struct subprocess_info *sub_info =
|
|
|
|
container_of(work, struct subprocess_info, work);
|
2012-03-23 16:02:48 -06:00
|
|
|
int wait = sub_info->wait & ~UMH_KILLABLE;
|
2010-05-26 15:43:04 -06:00
|
|
|
pid_t pid;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* CLONE_VFORK: wait until the usermode helper has execve'd
|
|
|
|
* successfully We need the data structures to stay around
|
|
|
|
* until that is done. */
|
2010-05-26 15:43:04 -06:00
|
|
|
if (wait == UMH_WAIT_PROC)
|
2005-04-16 16:20:36 -06:00
|
|
|
pid = kernel_thread(wait_for_helper, sub_info,
|
|
|
|
CLONE_FS | CLONE_FILES | SIGCHLD);
|
|
|
|
else
|
|
|
|
pid = kernel_thread(____call_usermodehelper, sub_info,
|
|
|
|
CLONE_VFORK | SIGCHLD);
|
|
|
|
|
2007-07-17 19:37:03 -06:00
|
|
|
switch (wait) {
|
|
|
|
case UMH_NO_WAIT:
|
2010-05-26 15:43:04 -06:00
|
|
|
call_usermodehelper_freeinfo(sub_info);
|
2007-07-17 19:37:03 -06:00
|
|
|
break;
|
2007-02-13 05:26:23 -07:00
|
|
|
|
2007-07-17 19:37:03 -06:00
|
|
|
case UMH_WAIT_PROC:
|
|
|
|
if (pid > 0)
|
|
|
|
break;
|
|
|
|
/* FALLTHROUGH */
|
|
|
|
case UMH_WAIT_EXEC:
|
2010-05-26 15:43:05 -06:00
|
|
|
if (pid < 0)
|
|
|
|
sub_info->retval = pid;
|
2012-03-23 16:02:47 -06:00
|
|
|
umh_complete(sub_info);
|
2007-07-17 19:37:03 -06:00
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2007-07-19 02:47:37 -06:00
|
|
|
/*
|
|
|
|
* If set, call_usermodehelper_exec() will exit immediately returning -EBUSY
|
|
|
|
* (used for preventing user land processes from being created after the user
|
|
|
|
* land has been frozen during a system-wide hibernation or suspend operation).
|
PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.
However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:
...
if (usermodehelper_is_disabled())
goto out;
/* Do actual work */
...
out:
return err;
Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.
In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.
Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
This patch adds proper synchronization to fix this issue.
It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09 15:36:36 -07:00
|
|
|
* Should always be manipulated under umhelper_sem acquired for write.
|
2007-07-19 02:47:37 -06:00
|
|
|
*/
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
static enum umh_disable_depth usermodehelper_disabled = UMH_DISABLED;
|
2007-07-19 02:47:37 -06:00
|
|
|
|
|
|
|
/* Number of helpers running */
|
|
|
|
static atomic_t running_helpers = ATOMIC_INIT(0);
|
|
|
|
|
|
|
|
/*
|
2011-11-15 13:59:21 -07:00
|
|
|
* Wait queue head used by usermodehelper_disable() to wait for all running
|
2007-07-19 02:47:37 -06:00
|
|
|
* helpers to finish.
|
|
|
|
*/
|
|
|
|
static DECLARE_WAIT_QUEUE_HEAD(running_helpers_waitq);
|
|
|
|
|
2012-03-28 15:30:02 -06:00
|
|
|
/*
|
|
|
|
* Used by usermodehelper_read_lock_wait() to wait for usermodehelper_disabled
|
|
|
|
* to become 'false'.
|
|
|
|
*/
|
|
|
|
static DECLARE_WAIT_QUEUE_HEAD(usermodehelper_disabled_waitq);
|
|
|
|
|
2007-07-19 02:47:37 -06:00
|
|
|
/*
|
|
|
|
* Time to wait for running_helpers to become zero before the setting of
|
2011-11-15 13:59:21 -07:00
|
|
|
* usermodehelper_disabled in usermodehelper_disable() fails
|
2007-07-19 02:47:37 -06:00
|
|
|
*/
|
|
|
|
#define RUNNING_HELPERS_TIMEOUT (5 * HZ)
|
|
|
|
|
2012-03-28 15:29:45 -06:00
|
|
|
int usermodehelper_read_trylock(void)
|
PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.
However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:
...
if (usermodehelper_is_disabled())
goto out;
/* Do actual work */
...
out:
return err;
Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.
In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.
Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
This patch adds proper synchronization to fix this issue.
It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09 15:36:36 -07:00
|
|
|
{
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
DEFINE_WAIT(wait);
|
2012-03-28 15:29:45 -06:00
|
|
|
int ret = 0;
|
|
|
|
|
PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.
However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:
...
if (usermodehelper_is_disabled())
goto out;
/* Do actual work */
...
out:
return err;
Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.
In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.
Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
This patch adds proper synchronization to fix this issue.
It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09 15:36:36 -07:00
|
|
|
down_read(&umhelper_sem);
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
for (;;) {
|
|
|
|
prepare_to_wait(&usermodehelper_disabled_waitq, &wait,
|
|
|
|
TASK_INTERRUPTIBLE);
|
|
|
|
if (!usermodehelper_disabled)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (usermodehelper_disabled == UMH_DISABLED)
|
|
|
|
ret = -EAGAIN;
|
|
|
|
|
2012-03-28 15:29:45 -06:00
|
|
|
up_read(&umhelper_sem);
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
|
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
|
|
|
|
schedule();
|
|
|
|
try_to_freeze();
|
|
|
|
|
|
|
|
down_read(&umhelper_sem);
|
2012-03-28 15:29:45 -06:00
|
|
|
}
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
finish_wait(&usermodehelper_disabled_waitq, &wait);
|
2012-03-28 15:29:45 -06:00
|
|
|
return ret;
|
PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.
However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:
...
if (usermodehelper_is_disabled())
goto out;
/* Do actual work */
...
out:
return err;
Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.
In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.
Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
This patch adds proper synchronization to fix this issue.
It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09 15:36:36 -07:00
|
|
|
}
|
2012-03-28 15:29:45 -06:00
|
|
|
EXPORT_SYMBOL_GPL(usermodehelper_read_trylock);
|
PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.
However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:
...
if (usermodehelper_is_disabled())
goto out;
/* Do actual work */
...
out:
return err;
Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.
In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.
Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
This patch adds proper synchronization to fix this issue.
It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09 15:36:36 -07:00
|
|
|
|
2012-03-28 15:30:02 -06:00
|
|
|
long usermodehelper_read_lock_wait(long timeout)
|
|
|
|
{
|
|
|
|
DEFINE_WAIT(wait);
|
|
|
|
|
|
|
|
if (timeout < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
down_read(&umhelper_sem);
|
|
|
|
for (;;) {
|
|
|
|
prepare_to_wait(&usermodehelper_disabled_waitq, &wait,
|
|
|
|
TASK_UNINTERRUPTIBLE);
|
|
|
|
if (!usermodehelper_disabled)
|
|
|
|
break;
|
|
|
|
|
|
|
|
up_read(&umhelper_sem);
|
|
|
|
|
|
|
|
timeout = schedule_timeout(timeout);
|
|
|
|
if (!timeout)
|
|
|
|
break;
|
|
|
|
|
|
|
|
down_read(&umhelper_sem);
|
|
|
|
}
|
|
|
|
finish_wait(&usermodehelper_disabled_waitq, &wait);
|
|
|
|
return timeout;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usermodehelper_read_lock_wait);
|
|
|
|
|
2012-03-28 15:29:45 -06:00
|
|
|
void usermodehelper_read_unlock(void)
|
PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.
However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:
...
if (usermodehelper_is_disabled())
goto out;
/* Do actual work */
...
out:
return err;
Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.
In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.
Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
This patch adds proper synchronization to fix this issue.
It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09 15:36:36 -07:00
|
|
|
{
|
|
|
|
up_read(&umhelper_sem);
|
|
|
|
}
|
2012-03-28 15:29:45 -06:00
|
|
|
EXPORT_SYMBOL_GPL(usermodehelper_read_unlock);
|
PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.
However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:
...
if (usermodehelper_is_disabled())
goto out;
/* Do actual work */
...
out:
return err;
Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.
In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.
Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
This patch adds proper synchronization to fix this issue.
It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09 15:36:36 -07:00
|
|
|
|
2012-03-28 15:30:02 -06:00
|
|
|
/**
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
* __usermodehelper_set_disable_depth - Modify usermodehelper_disabled.
|
|
|
|
* depth: New value to assign to usermodehelper_disabled.
|
|
|
|
*
|
|
|
|
* Change the value of usermodehelper_disabled (under umhelper_sem locked for
|
|
|
|
* writing) and wakeup tasks waiting for it to change.
|
2012-03-28 15:30:02 -06:00
|
|
|
*/
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
void __usermodehelper_set_disable_depth(enum umh_disable_depth depth)
|
2012-03-28 15:30:02 -06:00
|
|
|
{
|
|
|
|
down_write(&umhelper_sem);
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
usermodehelper_disabled = depth;
|
2012-03-28 15:30:02 -06:00
|
|
|
wake_up(&usermodehelper_disabled_waitq);
|
|
|
|
up_write(&umhelper_sem);
|
|
|
|
}
|
|
|
|
|
2008-10-15 23:01:21 -06:00
|
|
|
/**
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
* __usermodehelper_disable - Prevent new helpers from being started.
|
|
|
|
* @depth: New value to assign to usermodehelper_disabled.
|
|
|
|
*
|
|
|
|
* Set usermodehelper_disabled to @depth and wait for running helpers to exit.
|
2008-10-15 23:01:21 -06:00
|
|
|
*/
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
int __usermodehelper_disable(enum umh_disable_depth depth)
|
2007-07-19 02:47:36 -06:00
|
|
|
{
|
2007-07-19 02:47:37 -06:00
|
|
|
long retval;
|
|
|
|
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
if (!depth)
|
|
|
|
return -EINVAL;
|
|
|
|
|
PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.
However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:
...
if (usermodehelper_is_disabled())
goto out;
/* Do actual work */
...
out:
return err;
Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.
In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.
Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
This patch adds proper synchronization to fix this issue.
It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09 15:36:36 -07:00
|
|
|
down_write(&umhelper_sem);
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
usermodehelper_disabled = depth;
|
PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.
However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:
...
if (usermodehelper_is_disabled())
goto out;
/* Do actual work */
...
out:
return err;
Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.
In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.
Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591
This patch adds proper synchronization to fix this issue.
It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09 15:36:36 -07:00
|
|
|
up_write(&umhelper_sem);
|
|
|
|
|
2008-10-15 23:01:21 -06:00
|
|
|
/*
|
|
|
|
* From now on call_usermodehelper_exec() won't start any new
|
|
|
|
* helpers, so it is sufficient if running_helpers turns out to
|
|
|
|
* be zero at one point (it may be increased later, but that
|
|
|
|
* doesn't matter).
|
|
|
|
*/
|
|
|
|
retval = wait_event_timeout(running_helpers_waitq,
|
2007-07-19 02:47:37 -06:00
|
|
|
atomic_read(&running_helpers) == 0,
|
|
|
|
RUNNING_HELPERS_TIMEOUT);
|
2008-10-15 23:01:21 -06:00
|
|
|
if (retval)
|
|
|
|
return 0;
|
2007-07-19 02:47:36 -06:00
|
|
|
|
PM / Sleep: Mitigate race between the freezer and request_firmware()
There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.
To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.
For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED. The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer. Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately. This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled. [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
2012-03-28 15:30:28 -06:00
|
|
|
__usermodehelper_set_disable_depth(UMH_ENABLED);
|
2008-10-15 23:01:21 -06:00
|
|
|
return -EAGAIN;
|
|
|
|
}
|
|
|
|
|
2007-07-19 02:47:37 -06:00
|
|
|
static void helper_lock(void)
|
|
|
|
{
|
|
|
|
atomic_inc(&running_helpers);
|
|
|
|
smp_mb__after_atomic_inc();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void helper_unlock(void)
|
|
|
|
{
|
|
|
|
if (atomic_dec_and_test(&running_helpers))
|
|
|
|
wake_up(&running_helpers_waitq);
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/**
|
2007-07-17 19:37:02 -06:00
|
|
|
* call_usermodehelper_setup - prepare to call a usermode helper
|
2007-07-26 11:40:56 -06:00
|
|
|
* @path: path to usermode executable
|
|
|
|
* @argv: arg vector for process
|
|
|
|
* @envp: environment for process
|
2008-07-25 02:45:38 -06:00
|
|
|
* @gfp_mask: gfp mask for memory allocation
|
2007-07-17 19:37:02 -06:00
|
|
|
*
|
2007-07-26 11:40:56 -06:00
|
|
|
* Returns either %NULL on allocation failure, or a subprocess_info
|
2007-07-17 19:37:02 -06:00
|
|
|
* structure. This should be passed to call_usermodehelper_exec to
|
|
|
|
* exec the process and free the structure.
|
|
|
|
*/
|
2008-07-25 02:45:38 -06:00
|
|
|
struct subprocess_info *call_usermodehelper_setup(char *path, char **argv,
|
|
|
|
char **envp, gfp_t gfp_mask)
|
2007-07-17 19:37:02 -06:00
|
|
|
{
|
|
|
|
struct subprocess_info *sub_info;
|
2008-07-25 02:45:38 -06:00
|
|
|
sub_info = kzalloc(sizeof(struct subprocess_info), gfp_mask);
|
2007-07-17 19:37:02 -06:00
|
|
|
if (!sub_info)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
INIT_WORK(&sub_info->work, __call_usermodehelper);
|
|
|
|
sub_info->path = path;
|
|
|
|
sub_info->argv = argv;
|
|
|
|
sub_info->envp = envp;
|
|
|
|
out:
|
|
|
|
return sub_info;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(call_usermodehelper_setup);
|
|
|
|
|
|
|
|
/**
|
kmod: add init function to usermodehelper
About 6 months ago, I made a set of changes to how the core-dump-to-a-pipe
feature in the kernel works. We had reports of several races, including
some reports of apps bypassing our recursion check so that a process that
was forked as part of a core_pattern setup could infinitely crash and
refork until the system crashed.
We fixed those by improving our recursion checks. The new check basically
refuses to fork a process if its core limit is zero, which works well.
Unfortunately, I've been getting grief from maintainer of user space
programs that are inserted as the forked process of core_pattern. They
contend that in order for their programs (such as abrt and apport) to
work, all the running processes in a system must have their core limits
set to a non-zero value, to which I say 'yes'. I did this by design, and
think thats the right way to do things.
But I've been asked to ease this burden on user space enough times that I
thought I would take a look at it. The first suggestion was to make the
recursion check fail on a non-zero 'special' number, like one. That way
the core collector process could set its core size ulimit to 1, and enable
the kernel's recursion detection. This isn't a bad idea on the surface,
but I don't like it since its opt-in, in that if a program like abrt or
apport has a bug and fails to set such a core limit, we're left with a
recursively crashing system again.
So I've come up with this. What I've done is modify the
call_usermodehelper api such that an extra parameter is added, a function
pointer which will be called by the user helper task, after it forks, but
before it exec's the required process. This will give the caller the
opportunity to get a call back in the processes context, allowing it to do
whatever it needs to to the process in the kernel prior to exec-ing the
user space code. In the case of do_coredump, this callback is ues to set
the core ulimit of the helper process to 1. This elimnates the opt-in
problem that I had above, as it allows the ulimit for core sizes to be set
to the value of 1, which is what the recursion check looks for in
do_coredump.
This patch:
Create new function call_usermodehelper_fns() and allow it to assign both
an init and cleanup function, as we'll as arbitrary data.
The init function is called from the context of the forked process and
allows for customization of the helper process prior to calling exec. Its
return code gates the continuation of the process, or causes its exit.
Also add an arbitrary data pointer to the subprocess_info struct allowing
for data to be passed from the caller to the new process, and the
subsequent cleanup process
Also, use this patch to cleanup the cleanup function. It currently takes
an argp and envp pointer for freeing, which is ugly. Lets instead just
make the subprocess_info structure public, and pass that to the cleanup
and init routines
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-26 15:42:58 -06:00
|
|
|
* call_usermodehelper_setfns - set a cleanup/init function
|
2007-07-17 19:37:02 -06:00
|
|
|
* @info: a subprocess_info returned by call_usermodehelper_setup
|
|
|
|
* @cleanup: a cleanup function
|
kmod: add init function to usermodehelper
About 6 months ago, I made a set of changes to how the core-dump-to-a-pipe
feature in the kernel works. We had reports of several races, including
some reports of apps bypassing our recursion check so that a process that
was forked as part of a core_pattern setup could infinitely crash and
refork until the system crashed.
We fixed those by improving our recursion checks. The new check basically
refuses to fork a process if its core limit is zero, which works well.
Unfortunately, I've been getting grief from maintainer of user space
programs that are inserted as the forked process of core_pattern. They
contend that in order for their programs (such as abrt and apport) to
work, all the running processes in a system must have their core limits
set to a non-zero value, to which I say 'yes'. I did this by design, and
think thats the right way to do things.
But I've been asked to ease this burden on user space enough times that I
thought I would take a look at it. The first suggestion was to make the
recursion check fail on a non-zero 'special' number, like one. That way
the core collector process could set its core size ulimit to 1, and enable
the kernel's recursion detection. This isn't a bad idea on the surface,
but I don't like it since its opt-in, in that if a program like abrt or
apport has a bug and fails to set such a core limit, we're left with a
recursively crashing system again.
So I've come up with this. What I've done is modify the
call_usermodehelper api such that an extra parameter is added, a function
pointer which will be called by the user helper task, after it forks, but
before it exec's the required process. This will give the caller the
opportunity to get a call back in the processes context, allowing it to do
whatever it needs to to the process in the kernel prior to exec-ing the
user space code. In the case of do_coredump, this callback is ues to set
the core ulimit of the helper process to 1. This elimnates the opt-in
problem that I had above, as it allows the ulimit for core sizes to be set
to the value of 1, which is what the recursion check looks for in
do_coredump.
This patch:
Create new function call_usermodehelper_fns() and allow it to assign both
an init and cleanup function, as we'll as arbitrary data.
The init function is called from the context of the forked process and
allows for customization of the helper process prior to calling exec. Its
return code gates the continuation of the process, or causes its exit.
Also add an arbitrary data pointer to the subprocess_info struct allowing
for data to be passed from the caller to the new process, and the
subsequent cleanup process
Also, use this patch to cleanup the cleanup function. It currently takes
an argp and envp pointer for freeing, which is ugly. Lets instead just
make the subprocess_info structure public, and pass that to the cleanup
and init routines
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-26 15:42:58 -06:00
|
|
|
* @init: an init function
|
|
|
|
* @data: arbitrary context sensitive data
|
|
|
|
*
|
|
|
|
* The init function is used to customize the helper process prior to
|
|
|
|
* exec. A non-zero return code causes the process to error out, exit,
|
|
|
|
* and return the failure to the calling process
|
2007-07-17 19:37:02 -06:00
|
|
|
*
|
kmod: add init function to usermodehelper
About 6 months ago, I made a set of changes to how the core-dump-to-a-pipe
feature in the kernel works. We had reports of several races, including
some reports of apps bypassing our recursion check so that a process that
was forked as part of a core_pattern setup could infinitely crash and
refork until the system crashed.
We fixed those by improving our recursion checks. The new check basically
refuses to fork a process if its core limit is zero, which works well.
Unfortunately, I've been getting grief from maintainer of user space
programs that are inserted as the forked process of core_pattern. They
contend that in order for their programs (such as abrt and apport) to
work, all the running processes in a system must have their core limits
set to a non-zero value, to which I say 'yes'. I did this by design, and
think thats the right way to do things.
But I've been asked to ease this burden on user space enough times that I
thought I would take a look at it. The first suggestion was to make the
recursion check fail on a non-zero 'special' number, like one. That way
the core collector process could set its core size ulimit to 1, and enable
the kernel's recursion detection. This isn't a bad idea on the surface,
but I don't like it since its opt-in, in that if a program like abrt or
apport has a bug and fails to set such a core limit, we're left with a
recursively crashing system again.
So I've come up with this. What I've done is modify the
call_usermodehelper api such that an extra parameter is added, a function
pointer which will be called by the user helper task, after it forks, but
before it exec's the required process. This will give the caller the
opportunity to get a call back in the processes context, allowing it to do
whatever it needs to to the process in the kernel prior to exec-ing the
user space code. In the case of do_coredump, this callback is ues to set
the core ulimit of the helper process to 1. This elimnates the opt-in
problem that I had above, as it allows the ulimit for core sizes to be set
to the value of 1, which is what the recursion check looks for in
do_coredump.
This patch:
Create new function call_usermodehelper_fns() and allow it to assign both
an init and cleanup function, as we'll as arbitrary data.
The init function is called from the context of the forked process and
allows for customization of the helper process prior to calling exec. Its
return code gates the continuation of the process, or causes its exit.
Also add an arbitrary data pointer to the subprocess_info struct allowing
for data to be passed from the caller to the new process, and the
subsequent cleanup process
Also, use this patch to cleanup the cleanup function. It currently takes
an argp and envp pointer for freeing, which is ugly. Lets instead just
make the subprocess_info structure public, and pass that to the cleanup
and init routines
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-26 15:42:58 -06:00
|
|
|
* The cleanup function is just before ethe subprocess_info is about to
|
2007-07-17 19:37:02 -06:00
|
|
|
* be freed. This can be used for freeing the argv and envp. The
|
|
|
|
* Function must be runnable in either a process context or the
|
|
|
|
* context in which call_usermodehelper_exec is called.
|
|
|
|
*/
|
kmod: add init function to usermodehelper
About 6 months ago, I made a set of changes to how the core-dump-to-a-pipe
feature in the kernel works. We had reports of several races, including
some reports of apps bypassing our recursion check so that a process that
was forked as part of a core_pattern setup could infinitely crash and
refork until the system crashed.
We fixed those by improving our recursion checks. The new check basically
refuses to fork a process if its core limit is zero, which works well.
Unfortunately, I've been getting grief from maintainer of user space
programs that are inserted as the forked process of core_pattern. They
contend that in order for their programs (such as abrt and apport) to
work, all the running processes in a system must have their core limits
set to a non-zero value, to which I say 'yes'. I did this by design, and
think thats the right way to do things.
But I've been asked to ease this burden on user space enough times that I
thought I would take a look at it. The first suggestion was to make the
recursion check fail on a non-zero 'special' number, like one. That way
the core collector process could set its core size ulimit to 1, and enable
the kernel's recursion detection. This isn't a bad idea on the surface,
but I don't like it since its opt-in, in that if a program like abrt or
apport has a bug and fails to set such a core limit, we're left with a
recursively crashing system again.
So I've come up with this. What I've done is modify the
call_usermodehelper api such that an extra parameter is added, a function
pointer which will be called by the user helper task, after it forks, but
before it exec's the required process. This will give the caller the
opportunity to get a call back in the processes context, allowing it to do
whatever it needs to to the process in the kernel prior to exec-ing the
user space code. In the case of do_coredump, this callback is ues to set
the core ulimit of the helper process to 1. This elimnates the opt-in
problem that I had above, as it allows the ulimit for core sizes to be set
to the value of 1, which is what the recursion check looks for in
do_coredump.
This patch:
Create new function call_usermodehelper_fns() and allow it to assign both
an init and cleanup function, as we'll as arbitrary data.
The init function is called from the context of the forked process and
allows for customization of the helper process prior to calling exec. Its
return code gates the continuation of the process, or causes its exit.
Also add an arbitrary data pointer to the subprocess_info struct allowing
for data to be passed from the caller to the new process, and the
subsequent cleanup process
Also, use this patch to cleanup the cleanup function. It currently takes
an argp and envp pointer for freeing, which is ugly. Lets instead just
make the subprocess_info structure public, and pass that to the cleanup
and init routines
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-26 15:42:58 -06:00
|
|
|
void call_usermodehelper_setfns(struct subprocess_info *info,
|
2011-06-17 04:25:59 -06:00
|
|
|
int (*init)(struct subprocess_info *info, struct cred *new),
|
kmod: add init function to usermodehelper
About 6 months ago, I made a set of changes to how the core-dump-to-a-pipe
feature in the kernel works. We had reports of several races, including
some reports of apps bypassing our recursion check so that a process that
was forked as part of a core_pattern setup could infinitely crash and
refork until the system crashed.
We fixed those by improving our recursion checks. The new check basically
refuses to fork a process if its core limit is zero, which works well.
Unfortunately, I've been getting grief from maintainer of user space
programs that are inserted as the forked process of core_pattern. They
contend that in order for their programs (such as abrt and apport) to
work, all the running processes in a system must have their core limits
set to a non-zero value, to which I say 'yes'. I did this by design, and
think thats the right way to do things.
But I've been asked to ease this burden on user space enough times that I
thought I would take a look at it. The first suggestion was to make the
recursion check fail on a non-zero 'special' number, like one. That way
the core collector process could set its core size ulimit to 1, and enable
the kernel's recursion detection. This isn't a bad idea on the surface,
but I don't like it since its opt-in, in that if a program like abrt or
apport has a bug and fails to set such a core limit, we're left with a
recursively crashing system again.
So I've come up with this. What I've done is modify the
call_usermodehelper api such that an extra parameter is added, a function
pointer which will be called by the user helper task, after it forks, but
before it exec's the required process. This will give the caller the
opportunity to get a call back in the processes context, allowing it to do
whatever it needs to to the process in the kernel prior to exec-ing the
user space code. In the case of do_coredump, this callback is ues to set
the core ulimit of the helper process to 1. This elimnates the opt-in
problem that I had above, as it allows the ulimit for core sizes to be set
to the value of 1, which is what the recursion check looks for in
do_coredump.
This patch:
Create new function call_usermodehelper_fns() and allow it to assign both
an init and cleanup function, as we'll as arbitrary data.
The init function is called from the context of the forked process and
allows for customization of the helper process prior to calling exec. Its
return code gates the continuation of the process, or causes its exit.
Also add an arbitrary data pointer to the subprocess_info struct allowing
for data to be passed from the caller to the new process, and the
subsequent cleanup process
Also, use this patch to cleanup the cleanup function. It currently takes
an argp and envp pointer for freeing, which is ugly. Lets instead just
make the subprocess_info structure public, and pass that to the cleanup
and init routines
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-26 15:42:58 -06:00
|
|
|
void (*cleanup)(struct subprocess_info *info),
|
|
|
|
void *data)
|
2007-07-17 19:37:02 -06:00
|
|
|
{
|
|
|
|
info->cleanup = cleanup;
|
kmod: add init function to usermodehelper
About 6 months ago, I made a set of changes to how the core-dump-to-a-pipe
feature in the kernel works. We had reports of several races, including
some reports of apps bypassing our recursion check so that a process that
was forked as part of a core_pattern setup could infinitely crash and
refork until the system crashed.
We fixed those by improving our recursion checks. The new check basically
refuses to fork a process if its core limit is zero, which works well.
Unfortunately, I've been getting grief from maintainer of user space
programs that are inserted as the forked process of core_pattern. They
contend that in order for their programs (such as abrt and apport) to
work, all the running processes in a system must have their core limits
set to a non-zero value, to which I say 'yes'. I did this by design, and
think thats the right way to do things.
But I've been asked to ease this burden on user space enough times that I
thought I would take a look at it. The first suggestion was to make the
recursion check fail on a non-zero 'special' number, like one. That way
the core collector process could set its core size ulimit to 1, and enable
the kernel's recursion detection. This isn't a bad idea on the surface,
but I don't like it since its opt-in, in that if a program like abrt or
apport has a bug and fails to set such a core limit, we're left with a
recursively crashing system again.
So I've come up with this. What I've done is modify the
call_usermodehelper api such that an extra parameter is added, a function
pointer which will be called by the user helper task, after it forks, but
before it exec's the required process. This will give the caller the
opportunity to get a call back in the processes context, allowing it to do
whatever it needs to to the process in the kernel prior to exec-ing the
user space code. In the case of do_coredump, this callback is ues to set
the core ulimit of the helper process to 1. This elimnates the opt-in
problem that I had above, as it allows the ulimit for core sizes to be set
to the value of 1, which is what the recursion check looks for in
do_coredump.
This patch:
Create new function call_usermodehelper_fns() and allow it to assign both
an init and cleanup function, as we'll as arbitrary data.
The init function is called from the context of the forked process and
allows for customization of the helper process prior to calling exec. Its
return code gates the continuation of the process, or causes its exit.
Also add an arbitrary data pointer to the subprocess_info struct allowing
for data to be passed from the caller to the new process, and the
subsequent cleanup process
Also, use this patch to cleanup the cleanup function. It currently takes
an argp and envp pointer for freeing, which is ugly. Lets instead just
make the subprocess_info structure public, and pass that to the cleanup
and init routines
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-26 15:42:58 -06:00
|
|
|
info->init = init;
|
|
|
|
info->data = data;
|
2007-07-17 19:37:02 -06:00
|
|
|
}
|
kmod: add init function to usermodehelper
About 6 months ago, I made a set of changes to how the core-dump-to-a-pipe
feature in the kernel works. We had reports of several races, including
some reports of apps bypassing our recursion check so that a process that
was forked as part of a core_pattern setup could infinitely crash and
refork until the system crashed.
We fixed those by improving our recursion checks. The new check basically
refuses to fork a process if its core limit is zero, which works well.
Unfortunately, I've been getting grief from maintainer of user space
programs that are inserted as the forked process of core_pattern. They
contend that in order for their programs (such as abrt and apport) to
work, all the running processes in a system must have their core limits
set to a non-zero value, to which I say 'yes'. I did this by design, and
think thats the right way to do things.
But I've been asked to ease this burden on user space enough times that I
thought I would take a look at it. The first suggestion was to make the
recursion check fail on a non-zero 'special' number, like one. That way
the core collector process could set its core size ulimit to 1, and enable
the kernel's recursion detection. This isn't a bad idea on the surface,
but I don't like it since its opt-in, in that if a program like abrt or
apport has a bug and fails to set such a core limit, we're left with a
recursively crashing system again.
So I've come up with this. What I've done is modify the
call_usermodehelper api such that an extra parameter is added, a function
pointer which will be called by the user helper task, after it forks, but
before it exec's the required process. This will give the caller the
opportunity to get a call back in the processes context, allowing it to do
whatever it needs to to the process in the kernel prior to exec-ing the
user space code. In the case of do_coredump, this callback is ues to set
the core ulimit of the helper process to 1. This elimnates the opt-in
problem that I had above, as it allows the ulimit for core sizes to be set
to the value of 1, which is what the recursion check looks for in
do_coredump.
This patch:
Create new function call_usermodehelper_fns() and allow it to assign both
an init and cleanup function, as we'll as arbitrary data.
The init function is called from the context of the forked process and
allows for customization of the helper process prior to calling exec. Its
return code gates the continuation of the process, or causes its exit.
Also add an arbitrary data pointer to the subprocess_info struct allowing
for data to be passed from the caller to the new process, and the
subsequent cleanup process
Also, use this patch to cleanup the cleanup function. It currently takes
an argp and envp pointer for freeing, which is ugly. Lets instead just
make the subprocess_info structure public, and pass that to the cleanup
and init routines
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-26 15:42:58 -06:00
|
|
|
EXPORT_SYMBOL(call_usermodehelper_setfns);
|
2007-07-17 19:37:02 -06:00
|
|
|
|
|
|
|
/**
|
|
|
|
* call_usermodehelper_exec - start a usermode application
|
|
|
|
* @sub_info: information about the subprocessa
|
2005-04-16 16:20:36 -06:00
|
|
|
* @wait: wait for the application to finish and return status.
|
2007-02-13 05:26:23 -07:00
|
|
|
* when -1 don't wait at all, but you get no useful error back when
|
|
|
|
* the program couldn't be exec'ed. This makes it safe to call
|
|
|
|
* from interrupt context.
|
2005-04-16 16:20:36 -06:00
|
|
|
*
|
|
|
|
* Runs a user-space application. The application is started
|
|
|
|
* asynchronously if wait is not set, and runs as a child of keventd.
|
|
|
|
* (ie. it runs with full root capabilities).
|
|
|
|
*/
|
2012-03-23 16:02:48 -06:00
|
|
|
int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2006-07-03 01:25:26 -06:00
|
|
|
DECLARE_COMPLETION_ONSTACK(done);
|
2008-01-17 16:21:21 -07:00
|
|
|
int retval = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2007-07-19 02:47:37 -06:00
|
|
|
helper_lock();
|
2008-01-17 16:21:21 -07:00
|
|
|
if (sub_info->path[0] == '\0')
|
2007-07-17 19:37:02 -06:00
|
|
|
goto out;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2007-07-19 02:47:36 -06:00
|
|
|
if (!khelper_wq || usermodehelper_disabled) {
|
2007-07-17 19:37:02 -06:00
|
|
|
retval = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
2007-02-13 05:26:23 -07:00
|
|
|
|
|
|
|
sub_info->complete = &done;
|
|
|
|
sub_info->wait = wait;
|
|
|
|
|
|
|
|
queue_work(khelper_wq, &sub_info->work);
|
2008-01-17 16:21:21 -07:00
|
|
|
if (wait == UMH_NO_WAIT) /* task has freed sub_info */
|
|
|
|
goto unlock;
|
2012-03-23 16:02:47 -06:00
|
|
|
|
|
|
|
if (wait & UMH_KILLABLE) {
|
|
|
|
retval = wait_for_completion_killable(&done);
|
|
|
|
if (!retval)
|
|
|
|
goto wait_done;
|
|
|
|
|
|
|
|
/* umh_complete() will see NULL and free sub_info */
|
|
|
|
if (xchg(&sub_info->complete, NULL))
|
|
|
|
goto unlock;
|
|
|
|
/* fallthrough, umh_complete() was already called */
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
wait_for_completion(&done);
|
2012-03-23 16:02:47 -06:00
|
|
|
wait_done:
|
2007-02-13 05:26:23 -07:00
|
|
|
retval = sub_info->retval;
|
2008-01-17 16:21:21 -07:00
|
|
|
out:
|
2007-07-17 19:37:02 -06:00
|
|
|
call_usermodehelper_freeinfo(sub_info);
|
2008-01-17 16:21:21 -07:00
|
|
|
unlock:
|
2007-07-19 02:47:37 -06:00
|
|
|
helper_unlock();
|
2007-02-13 05:26:23 -07:00
|
|
|
return retval;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2007-07-17 19:37:02 -06:00
|
|
|
EXPORT_SYMBOL(call_usermodehelper_exec);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2011-04-01 15:07:50 -06:00
|
|
|
static int proc_cap_handler(struct ctl_table *table, int write,
|
|
|
|
void __user *buffer, size_t *lenp, loff_t *ppos)
|
|
|
|
{
|
|
|
|
struct ctl_table t;
|
|
|
|
unsigned long cap_array[_KERNEL_CAPABILITY_U32S];
|
|
|
|
kernel_cap_t new_cap;
|
|
|
|
int err, i;
|
|
|
|
|
|
|
|
if (write && (!capable(CAP_SETPCAP) ||
|
|
|
|
!capable(CAP_SYS_MODULE)))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* convert from the global kernel_cap_t to the ulong array to print to
|
|
|
|
* userspace if this is a read.
|
|
|
|
*/
|
|
|
|
spin_lock(&umh_sysctl_lock);
|
|
|
|
for (i = 0; i < _KERNEL_CAPABILITY_U32S; i++) {
|
|
|
|
if (table->data == CAP_BSET)
|
|
|
|
cap_array[i] = usermodehelper_bset.cap[i];
|
|
|
|
else if (table->data == CAP_PI)
|
|
|
|
cap_array[i] = usermodehelper_inheritable.cap[i];
|
|
|
|
else
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
spin_unlock(&umh_sysctl_lock);
|
|
|
|
|
|
|
|
t = *table;
|
|
|
|
t.data = &cap_array;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* actually read or write and array of ulongs from userspace. Remember
|
|
|
|
* these are least significant 32 bits first
|
|
|
|
*/
|
|
|
|
err = proc_doulongvec_minmax(&t, write, buffer, lenp, ppos);
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* convert from the sysctl array of ulongs to the kernel_cap_t
|
|
|
|
* internal representation
|
|
|
|
*/
|
|
|
|
for (i = 0; i < _KERNEL_CAPABILITY_U32S; i++)
|
|
|
|
new_cap.cap[i] = cap_array[i];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Drop everything not in the new_cap (but don't add things)
|
|
|
|
*/
|
|
|
|
spin_lock(&umh_sysctl_lock);
|
|
|
|
if (write) {
|
|
|
|
if (table->data == CAP_BSET)
|
|
|
|
usermodehelper_bset = cap_intersect(usermodehelper_bset, new_cap);
|
|
|
|
if (table->data == CAP_PI)
|
|
|
|
usermodehelper_inheritable = cap_intersect(usermodehelper_inheritable, new_cap);
|
|
|
|
}
|
|
|
|
spin_unlock(&umh_sysctl_lock);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct ctl_table usermodehelper_table[] = {
|
|
|
|
{
|
|
|
|
.procname = "bset",
|
|
|
|
.data = CAP_BSET,
|
|
|
|
.maxlen = _KERNEL_CAPABILITY_U32S * sizeof(unsigned long),
|
|
|
|
.mode = 0600,
|
|
|
|
.proc_handler = proc_cap_handler,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.procname = "inheritable",
|
|
|
|
.data = CAP_PI,
|
|
|
|
.maxlen = _KERNEL_CAPABILITY_U32S * sizeof(unsigned long),
|
|
|
|
.mode = 0600,
|
|
|
|
.proc_handler = proc_cap_handler,
|
|
|
|
},
|
|
|
|
{ }
|
|
|
|
};
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
void __init usermodehelper_init(void)
|
|
|
|
{
|
|
|
|
khelper_wq = create_singlethread_workqueue("khelper");
|
|
|
|
BUG_ON(!khelper_wq);
|
|
|
|
}
|