Fixes a compile error in call_usermodehelper_async and changes kset_hotplug
to use call_usermodehelper_async, since it is called with a semaphore held,
which can result in a deadlock.
---
diff -puN kernel/kmod.c~call_usermodehelper_kobject kernel/kmod.c
--- linux-2.6.5/kernel/kmod.c~call_usermodehelper_kobject Mon Apr 12 08:27:20 2004
+++ linux-2.6.5-bjking1/kernel/kmod.c Mon Apr 12 08:27:44 2004
@@ -296,7 +296,7 @@ int call_usermodehelper_async(char *path
{
struct subprocess_info *sub_info;
- if (system_state != SYSTEM_RUNNING)
+ if (!system_running)
return -EBUSY;
if (path[0] == '\0')
goto out;
diff -puN lib/kobject.c~call_usermodehelper_kobject lib/kobject.c
--- linux-2.6.5/lib/kobject.c~call_usermodehelper_kobject Mon Apr 12 08:28:07 2004
+++ linux-2.6.5-bjking1/lib/kobject.c Mon Apr 12 08:28:28 2004
@@ -187,7 +187,7 @@ static void kset_hotplug(const char *act
pr_debug ("%s: %s %s %s %s %s %s %s\n", __FUNCTION__, argv[0], argv[1],
envp[0], envp[1], envp[2], envp[3], envp[4]);
- retval = call_usermodehelper (argv[0], argv, envp, 0);
+ retval = call_usermodehelper_async (argv[0], argv, envp, GFP_KERNEL);
if (retval)
pr_debug ("%s - call_usermodehelper returned %d\n",
__FUNCTION__, retval);
_
Brian King <[email protected]> wrote:
>
> >> Ok, you've convinced me of the mess that would cause. So what should we
> >> do to help fix this? Serialize call_usermodehelper()?
> >
> >
> > May as well bring back call_usermodehelper_async() I guess.
> >
> >
> > There are two patches here, and they are totally untested...
>
> I loaded the patches on my ppc64 box and they worked fine after I fixed a compile
> bug. The attached patch fixes the compile bug and changes the call_usermodehelper
> call in kset_hotplug to call_usermodehelper_async.
yup, thanks. I've changed the patch in my tree so that we always perform
the fully-async operation if call_usermodehelper() is passed "wait=0". It
gets the new code some more testing and keeps the kernel API simpler.