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??.
Received on Tue Oct 25 00:55:48 2011