Greg KH wrote:
> On Wed, Apr 07, 2004 at 05:58:46PM -0500, Brian King wrote:
> 
>>The following patch fixes a deadlock experienced when devices are
>>being added to a bus both from a user process and eventd process.
>>The eventd process was hung waiting on dev->bus->subsys.rwsem which
>>was held by another process, which was hung since it was calling 
>>call_usermodehelper directly which was hung waiting for work scheduled
>>on the eventd workqueue to complete. The patch fixes this by delaying
>>the kobject_hotplug work, running it from eventd if possible. 
> 
> 
> But why?  Will this not still cause the same deadlock eventually?  The
> call_usermodehelper function uses keventd, so what about users who call
> that function directly?

It fixes the problem as long as the rule of not holding locks/semaphores
when calling call_usermodehelper holds. I don't see how the deadlock can occur
for the scenario I hit with the fix, since the hotplug action runs completely
asynchronously without the semaphore that was causing the deadlock. Now, could
there be other places in the kernel today that call call_usermodehelper with
locks that could also have deadlock issues? Probably.

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.

> Also, you gratitously changed some of the whitespace in the file you
> were modifying, which isn't a nice thing to do :)

Sorry about that. Attached is a patch which fixes this. If call_usermodehelper
is the proper place to fix this, then I'll look into rolling a new patch.


Thanks

-Brian



-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center