From: Greg KH <greg@kroah.com>
To: Andrew Morton <akpm@osdl.org>
Cc: brking@us.ibm.com, linux-kernel@vger.kernel.org,
linux-hotplug-devel@lists.sourceforge.net
Subject: Re: [PATCH] call_usermodehelper hang
Date: Sat, 10 Apr 2004 09:53:22 -0700 [thread overview]
Message-ID: <20040410165322.GG1317@kroah.com> (raw)
In-Reply-To: <20040409141511.4e372554.akpm@osdl.org>
On Fri, Apr 09, 2004 at 02:15:11PM -0700, Andrew Morton wrote:
> Greg KH <greg@kroah.com> wrote:
> >
> > On Fri, Apr 09, 2004 at 03:42:56PM -0500, Brian King wrote:
> > > Would you prefer a fix in call_usermodehelper itself? It could certainly
> > > be argued that calling call_usermodehelper with wait=0 should be allowed
> > > even when holding locks. Although, fixing it here is less obvious to me
> > > how to do because of the arguments to call_usermodehelper. I would imagine
> > > it would consist of creating a kernel_thread to preserve the caller's stack.
> >
> > Yes, I think call_usermodehelper should be changed to create a new
> > kernel thread for every call.
>
> It does that already. But that thread is parented by keventd. This was
> done to avoid all the various nasty things which can happen when you have a
> kernel thread and a hotplug helper which are parented by a random userspace
> process. All the crap which it might have inherited: uid? gid? signals?
> nice? rtprio? rlimits? namespace?
Yeah, good point.
> 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()?
thanks,
greg k-h
next prev parent reply other threads:[~2004-04-10 17:02 UTC|newest]
Thread overview: 19+ 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-09 20:42 ` Brian King
2004-04-09 20:53 ` Greg KH
2004-04-09 21:05 ` Brian King
2004-04-09 21:15 ` Andrew Morton
2004-04-10 16:53 ` Greg KH [this message]
2004-04-10 20:11 ` Andrew Morton
2004-04-12 15:25 ` Brian King
2004-04-12 17:46 ` Andrew Morton
2004-04-16 17:55 ` Brian King
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=20040410165322.GG1317@kroah.com \
--to=greg@kroah.com \
--cc=akpm@osdl.org \
--cc=brking@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).