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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:54 UTC