Date: Sat, 30 Nov 2002 13:10:55 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Michal Mertl <mime@traveller.cz> Cc: current@freebsd.org Subject: Re: system locks with vnode backed md(4) Message-ID: <Pine.NEB.3.96L.1021130130417.77446C-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.41.0211301833040.82532-100000@prg.traveller.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021130130417.77446C-100000>