various vfs LORs

[Kostik Belousov]

On Wed, Aug 26, 2009 at 10:48:13AM -0400, Rick Macklem wrote:
> 
> 
> 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?
Yes, sounds right. You could see similar workaround in devfs,
fs/devfs/devfs_vnops.c:404, also in the place where new vnode is
instantiated.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090826/9d824704/attachment.pgp