From: Brian King <brking@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Greg KH <greg@kroah.com>,
linux-kernel@vger.kernel.org,
linux-hotplug-devel@lists.sourceforge.net
Subject: Re: [PATCH] call_usermodehelper hang
Date: Mon, 12 Apr 2004 15:25:49 +0000 [thread overview]
Message-ID: <407AB4FD.4070905@us.ibm.com> (raw)
In-Reply-To: 20040410131137.0eff0ae2.akpm@osdl.org
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
Andrew Morton wrote:
> Greg KH <greg@kroah.com> wrote:
>
>>>The deadlock opportunity occurs during the call_usermodehelper() handoff to
>>
>> > keventd, which is synchronous.
>> >
>> > 2-3 years back I did have a call_usermodehelper() which was fully async.
>> > It was pretty unpleasant because of the need to atomically allocate
>> > arbitrary amounts of memory to hold the argv[] and endp[] arrays, to pass
>> > them between a couple of threads and to then correctly free it all up
>> > again.
>>
>> 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.
-Brian
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
[-- Attachment #2: call_usermodehelper_kobject.patch --]
[-- Type: text/plain, Size: 1253 bytes --]
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);
_
WARNING: multiple messages have this Message-ID (diff)
From: Brian King <brking@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Greg KH <greg@kroah.com>,
linux-kernel@vger.kernel.org,
linux-hotplug-devel@lists.sourceforge.net
Subject: Re: [PATCH] call_usermodehelper hang
Date: Mon, 12 Apr 2004 10:25:49 -0500 [thread overview]
Message-ID: <407AB4FD.4070905@us.ibm.com> (raw)
In-Reply-To: 20040410131137.0eff0ae2.akpm@osdl.org
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
Andrew Morton wrote:
> Greg KH <greg@kroah.com> wrote:
>
>>>The deadlock opportunity occurs during the call_usermodehelper() handoff to
>>
>> > keventd, which is synchronous.
>> >
>> > 2-3 years back I did have a call_usermodehelper() which was fully async.
>> > It was pretty unpleasant because of the need to atomically allocate
>> > arbitrary amounts of memory to hold the argv[] and endp[] arrays, to pass
>> > them between a couple of threads and to then correctly free it all up
>> > again.
>>
>> 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.
-Brian
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
[-- Attachment #2: call_usermodehelper_kobject.patch --]
[-- Type: text/plain, Size: 1253 bytes --]
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);
_
next prev parent reply other threads:[~2004-04-12 15:25 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-06 18:11 call_usermodehelper hang Brian King
2004-04-07 0:29 ` Andrew Morton
2004-04-07 6:11 ` Greg KH
2004-04-07 14:00 ` Brian King
2004-04-07 22:58 ` [PATCH] " Brian King
2004-04-08 22:47 ` Greg KH
2004-04-08 22:47 ` Greg KH
2004-04-09 20:42 ` Brian King
2004-04-09 20:42 ` Brian King
2004-04-09 20:53 ` Greg KH
2004-04-09 20:53 ` Greg KH
2004-04-09 21:05 ` Brian King
2004-04-09 21:05 ` Brian King
2004-04-09 21:15 ` Andrew Morton
2004-04-09 21:15 ` Andrew Morton
2004-04-10 16:53 ` Greg KH
2004-04-10 16:53 ` Greg KH
2004-04-10 20:11 ` Andrew Morton
2004-04-10 20:11 ` Andrew Morton
2004-04-12 15:25 ` Brian King [this message]
2004-04-12 15:25 ` Brian King
2004-04-12 17:46 ` Andrew Morton
2004-04-12 17:46 ` Andrew Morton
2004-04-16 17:55 ` Brian King
2004-04-16 17:55 ` Brian King
2004-04-12 18:49 ` Greg KH
2004-04-12 18:49 ` Greg KH
2004-04-08 23:17 ` Chris Wright
2004-04-07 0:41 ` Chris Wright
2004-04-07 1:46 ` Brian King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=407AB4FD.4070905@us.ibm.com \
--to=brking@us.ibm.com \
--cc=akpm@osdl.org \
--cc=greg@kroah.com \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.