Re: call_usermodehelper hang

[Brian King]

Greg KH wrote:
> On Tue, Apr 06, 2004 at 05:29:03PM -0700, Andrew Morton wrote:
>
> > Brian King <brking@xxxxxxxxxx> 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.

scsi_add_device is being called from keventd by the ipr LLD. I am assuming this
is a reasonable thing to do. If not, then I would argue the scsi_add_device API
is broken as it must be called from task level, and if a LLD cannot use keventd,
then every LLD that wants to use it would need to create its own workqueue thread.


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

-
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/