Re: kern/42228: Kernel deadlock prevents further file system access

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/42228; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/42228: Kernel deadlock prevents further file system access
Date: Mon, 21 Jun 2010 02:55:55 +0000

 On Sat, Jun 19, 2010 at 10:25:01PM +0000, Matthias Scheler wrote:
  >  Another deadlock today with a NetBSD/amd64 5.1_RC3. I examined
  >  multiple dozen of the processes which were stuck in "tstile" state.
  >  Most of them were stuck in open(2), stat(2) or execve(2). I found
  >  one "httpd" (Apache 2.2.15) process which was stuck in fcntl() trying
  >  to lock a file (it had called cv_timedwait() from lf_advlock()) but
  >  I'm not sure whether that was related.
 
 It might well be. Often with these things most or all of the processes
 in tstile state are queued behind the real problem, and the real
 problem often isn't in tstile state. Although this depends on what
 actually went wrong.
 
  >  Is there any way I can get more debugging information? How do I e.g.
  >  find the vnode based on a stack trace?
 
 The vnode is the first argument to most VOP_* functions (the VOP
 indirection points themselves, not the fs implementations of them),
 including VOP_LOCK, and is also frequently the first argument to
 fs-level functions below the ones that implement the vnode ops. If you
 get reliable arguments from ddb (which is always somewhat in doubt)
 finding the vnode involved usually isn't that hard.
 
 One of these days I should get around to writing a deadlock detector
 for LOCKDEBUG. It won't make LOCKDEBUG noticeably slower than it
 already is... :-)
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost