Comment 7 for bug 598335

I took a quick look and found all rtnl paths waiting on mutex_lock. The stuck tasks were gnome-panel, ureadahead and workqueues (modprobe, waiting on a lock).. I also found wpa_supplicant waiting on

[ 240.393172] [<c05739d5>] schedule_timeout+0x185/0x200
[ 240.393181] [<c012e7a0>] ? __wake_up_common+0x40/0x70
[ 240.393191] [<c0132f90>] ? __wake_up+0x40/0x50
[ 240.393200] [<c05736f2>] wait_for_common+0xa2/0x120
[ 240.393209] [<c013c4a0>] ? default_wake_function+0x0/0x10
[ 240.393218] [<c0573802>] wait_for_completion+0x12/0x20
[ 240.393228] [<c01568b7>] call_usermodehelper_exec+0xc7/0xd0

The rtnl_lock() is held in wext_ioctl_dispatch() (from what I can see).

Observations

1. I don't see cgroup showing up anywhere in the stack

Questions

1. What is the user mode helper? It seems like it is holding/blocking the rest of the system from making progress.

Can we please get the output of cat /proc/mounts and the cgroup filesystem output, please?