From owner-freebsd-current Sat Nov 30 10:11: 2 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4724037B401 for ; Sat, 30 Nov 2002 10:11:01 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7835F43EC2 for ; Sat, 30 Nov 2002 10:11:00 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gAUIAuBF027756; Sat, 30 Nov 2002 13:10:56 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 30 Nov 2002 13:10:55 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Michal Mertl Cc: current@freebsd.org Subject: Re: system locks with vnode backed md(4) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 30 Nov 2002, Michal Mertl wrote: > I'm now unable to make it dead-lock again. Yet it happened quite easily. > I had more md backing files in the same directory at the beginning (to > test Terry's suspicion mentioned in thread 'jail' on hackers@). I've noticed that chroot() environments tend to make existing deadlock opportunities more likely. I'm not quite sure why that is. :-) > I'll try to get more problems and get more info (show lockedvnods, show > locks). > > show locks with first dead-lock showed only Giant AFAIR. Yeah, vnode locks and other lockmgr locks don't show up in 'show locks', since only SMPng locking primitives are tracked by WITNESS. There are a fair number of vnode locking deadlock scenarios that are unavoidable where we rely on grabbing vnode locks out of the directory structure lock order. This occurs for vnode-backed md devices, quotas, and UFS1 extended attributes, and probably some other situations. I suspect that Terry is correct that operations on the vnode backing file storage directory are triggering the problem, since that increases the chances that a vnode lock "race to root" will occur from both the file system backed into the md device, and for the md backing vnodes during blocking I/O. If you can avoid directory operations on the md backing directory, that would probably be one way to avoid triggering the bug. Seeing it reproduced would probably confirm that this is the case. On the other hand, there may be other deadlocks in the vnode/ufs/md code that can be more easily corrected than this general VFS problem, so details there would be very useful. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message