Re: [PATCH] call_usermodehelper hang

[Greg KH]

On Fri, Apr 09, 2004 at 02:15:11PM -0700, Andrew Morton wrote:
> Greg KH <greg@xxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/