[lkml]   [2005]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-pm] Re: swsusp 'disk' fails in bk-current - intel_agp at fault?

On Wed, 2005-03-30 at 08:35, Pavel Machek wrote:
> Hi!
> > > We currently freeze processes for suspend-to-ram, too. I guess that
> > > disable_usermodehelper is probably better and that in_suspend() should
> > > only be used for sanity checks... go with disable_usermodehelper and
> > > sorry for the noise.
> >
> > Here's another possibility: Freeze the workqueue that
> > call_usermodehelper uses (remember that code I didn't push hard enough
> > to Andrew?), and let invocations of call_usermodehelper block in
> > TASK_UNINTERRUPTIBLE. In refrigerating processes, don't choke on
> There may be many devices in the system, and you are going to need
> quite a lot of RAM for all that... That's why they do not queue it
> during boot, IIRC. Disabling usermode helper seems right.

Many devices is true, but very few of them invoke usermode helpers.

[desktop build-2.6.12-rc1]# find -name *.[ch] | xargs grep usermodehelper
./drivers/s390/crypto/z90main.c: call_usermodehelper(argv[0], argv, envp, 0);
./drivers/net/hamradio/baycom_epp.c: return call_usermodehelper(eppconfig_path, argv, envp, 1);
./drivers/acpi/thermal.c: call_usermodehelper(argv[0], argv, envp, 0);
./drivers/acpi/thermal.mod.c: { 0x436006da, "call_usermodehelper" },
./drivers/input/input.c: value = call_usermodehelper(argv [0], argv, envp, 0);
./drivers/pnp/pnpbios/core.c: value = call_usermodehelper (argv [0], argv, envp, 0);
./drivers/macintosh/therm_pm72.c: return call_usermodehelper(critical_overtemp_path, argv, envp, 0);
./arch/i386/mach-voyager/voyager_thread.c: if ((ret = call_usermodehelper(argv[0], argv, envp, 1)) != 0) {
./include/linux/kmod.h:extern int call_usermodehelper(char *path, char *argv[], char *envp[], int wait);
./include/linux/kmod.h:extern void usermodehelper_init(void);
./kernel/power/main.c: return call_usermodehelper(argv[0], argv, envp, 1);
./kernel/power/suspend_userui.c: retval = call_usermodehelper(userui_program, argv, envp, 0);
./kernel/kmod.c: call_usermodehelper wait flag, and remove exec_usermodehelper.
./kernel/kmod.c: ret = call_usermodehelper(modprobe_path, argv, envp, 1);
./kernel/kmod.c:static int ____call_usermodehelper(void *data)
./kernel/kmod.c: pid = kernel_thread(____call_usermodehelper, sub_info, SIGCHLD);
./kernel/kmod.c:static void __call_usermodehelper(void *data)
./kernel/kmod.c: pid = kernel_thread(____call_usermodehelper, sub_info,
./kernel/kmod.c: * call_usermodehelper - start a usermode application
./kernel/kmod.c:int call_usermodehelper(char *path, char **argv, char **envp, int wait)
./kernel/kmod.c: DECLARE_WORK(work, __call_usermodehelper, &sub_info);
./kernel/kmod.c:void __init usermodehelper_init(void)
./kernel/cpuset.c: * Note final arg to call_usermodehelper() is 0 - that means
./kernel/cpuset.c: return call_usermodehelper(argv[0], argv, envp, 0);
./security/keys/request_key.c: return call_usermodehelper(argv[0], argv, envp, 1);
./lib/kobject_uevent.c: retval = call_usermodehelper (argv[0], argv, envp, 0);
./lib/kobject_uevent.c: pr_debug ("%s - call_usermodehelper returned %d\n",
./init/main.c: usermodehelper_init();

Of course there will be indirect invocations (via kobjects, for
example), but I still think the number is not that great. I'm already
using the method I suggested in unreleased Suspend2 code, and the only
invocation I'm catch is at resume time, for the keseriod.


Nigel Cunningham
Software Engineer, Canberra, Australia
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.076 / U:5.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site