Messages in this thread | | | Date | Tue, 6 Apr 2004 23:11:46 -0700 | From | Greg KH <> | Subject | Re: call_usermodehelper hang |
| |
On Tue, Apr 06, 2004 at 05:29:03PM -0700, Andrew Morton wrote: > Brian King <brking@us.ibm.com> wrote: > > > > I have been running into some kernel hangs due to call_usermodehelper. Looking > > at the backtrace, it looks to me like there are deadlock issues with adding > > devices from work queues. Attached is a sample backtrace from one of the > > hangs I experienced. My question is why does call_usermodehelper do 2 different > > things depending on whether or not it is called from the kevent task? It appears > > that the simple way to fix the hang would be to never have call_usermodehelper > > use a work_queue since it must be called from process context anyway, or > > am I missing something? > > > > swapper is running call_usermodehelper() while holding > down_write(&bus->subsys.rwsem); via bus_add_driver(). > > Meanwhile, keventd is blocked on the same lock in bus_add_device(). > > I'd say that the bug lies in the kobject code - we should not call > call_usermodehelper() while holding any locks which keventd may ever > acquire.
How is keventd calling sysfs code? Is scsi using it to drive device detection somehow? I don't see how the kobject core code itself can do this on its own.
thanks,
greg k-h - 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/
| |