Comment 12 for bug 845158

The best way to track this kernel lock bug are probably to recompile a kernel with lockdep enabled.

(11:40:44) xranby: mjw: can systemtap help diagnose kernel locks? i would like to know what part of the kernel are holding a &mm->mmap_sem semaphore
(11:42:20) xranby: all i currently know are all parts of the kernel gets stuck waiting for this semaphre to get released :/
(11:45:29) mjw: xranby, for that kind of kernel lock issue I would use lockdep
(11:47:38) mjw: https://www.kernel.org/doc/Documentation/lockdep-design.txt
(11:48:13) mjw: xranby, that does mean you want a kernel build with lockdep enabled
(11:48:17) mjw: which is slow
(11:48:30) xranby: sounds like a reasonable way to debug this
(11:48:45) xranby: http://lwn.net/Articles/321663/ found this lwn article on the subject as well
(11:48:55) xranby: thank you for the heads up of lockdep existance
(11:49:15) mjw: http://linuxplumbersconf.org/2011/ocw//system/presentations/153/original/lockdep-plumbers-2011.odp
(11:49:31) mjw: It is not as cool as using systemtap of course :)
(11:50:10) mjw: But for systemtap to help you with this issue you have to have some hint already where you suspect the problem might be
(11:50:21) mjw: if so, then you can set probes on the suspected functions
(11:50:35) mjw: and trace how/when/in-which-order they are called
(11:51:05) mjw: lockdep automates that for you (with the downside of having to recompile your kernel of course)