Date: Wed, 26 Aug 2009 10:48:13 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Kostik Belousov <kostikbel@gmail.com> Cc: "Rick C. Petty" <rick-freebsd2008@kiwi-computer.com>, bzeeb+freebsd+lor@zabbadoz.net, current@freebsd.org Subject: Re: various vfs LORs Message-ID: <Pine.GSO.4.63.0908261041090.21868@muncher.cs.uoguelph.ca> In-Reply-To: <20090821200957.GC9623@deviant.kiev.zoral.com.ua> References: <20090819161817.GA89704@keira.kiwi-computer.com> <20090819175029.GA90205@keira.kiwi-computer.com> <Pine.GSO.4.63.0908211402510.14428@muncher.cs.uoguelph.ca> <20090821200957.GC9623@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Aug 2009, Kostik Belousov wrote: >> >> Since the 3rd one is locking a newly allocated nfs vnode (that isn't yet >> in the mount point list, etc), I don't think this will cause a problem >> and I don't see an easy way to avoid it. > > We could add LK_NOWITNESS to nfsclient/nfs_subr.c:161. > Ok, I had thought LK_NOWITNESS was used for lockinit() and applied to the lock "forever" so it didn't seem like a good idea, but I just looked and it appears that LK_NOWITNESS can be used for vn_lock()/lockmgr() to apply to that lock call only? If so, this seems reasonable, so long as my analysis that it doesn't matter because it is a new nfs vnode (guaranteed to not yet be locked) and, as such, can't cause a deadlock. (I'm assuming that LORs are checked to try and avoid deadlocks or other nasties like sleeping for a sleep lock when a mutex is held.) Sound right? Thanks in advance for help with this, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0908261041090.21868>