Messages in this thread | | | Date | Fri, 9 Apr 2004 14:15:11 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] call_usermodehelper hang |
| |
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?
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |