On Mon, Oct 24, 2011 at 11:14:05AM +0200, Pawel Sikora wrote: > Hi, > i'm comming back with some news about cryptic > vserver crash described few months ago at > https://lkml.org/lkml/2011/5/23/398. > decrypted parts from the quite recent crash > http://pluto.agmk.net/kernel/vs-crash-3.0.3-vs2.3.1-pre10/ > have shown possible vfs-related deadlock. > git reports some vfs/dcache_lock cleanup in the 2.6.38 > kernel which exposes pivot_root() deadlock > http://www.spinics.net/lists/linux-fsdevel/msg43078.html > fixed in upstream by commit 27cb1572e3e6bb1f8cf6bb3d74c914a87b131792. > it looks like the vserver's mnt_is_reachable() does the same > bad locking scheme as original pivot_root() and leads to > deadlock on my opterons sooner (few minutes) or later (few > hours). mnt_is_reachable() takes a read lock while pivot_root() takes a write lock (vfsmount_lock), so they are not directly comparable > for tests i've commented out mnt_is_reachable() usage and > servers works pretty stable with full load again. the decoded crashes points toward problems with is_subdir() which might cause issues when called with the read lock held, and just removing the mnt_is_reachable() check might avoid this issue as well ... > could you please investigate this issue? the fact that without mnt_is_reachable() it seems to be (more) stable suggests to try with guests banging on show_vfsmnt to provoke the issue ... anyway, thanks for the info, Herbert > BR, > Pawe??.