Date: Thu, 17 Nov 2011 10:36:42 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-7@freebsd.org, Rick Macklem <rmacklem@FreeBSD.org> Subject: Re: svn commit: r227549 - stable/7/sys/nfsclient Message-ID: <20111117183642.GY1455@elvis.mu.org> In-Reply-To: <462306074.1954190.1321506994004.JavaMail.root@erie.cs.uoguelph.ca> References: <20111117040109.GU1455@elvis.mu.org> <462306074.1954190.1321506994004.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
* Rick Macklem <rmacklem@uoguelph.ca> [111116 21:16] wrote: > Alfred Perlstein wrote: > > Rick, I have a question, what will happen if the nfs_freesillyrename() > > call happens when the mount is down? Will it block the > > taskqueue_thread? > > > > If so, it might make more sense to make a taskqueue per mount point. > > > > If not, excuse me. :-) > > > Well, all nfs_freesillyrename() does is a vrele() on the parent > directory when the file node's use count has gone to 0. > I can't think why that would do any RPC, so I don't see a problem? > If you do see a problem with vrele() on the directory, please let me > know. > > The problem this fixes is a LOR that would occur when the vrele() on > the directory was done by the thread doing VOP_INACTIVE(), since it > already has the file vnode lock and the vrele() was locking the parent > directory. This could cause a fairly rare deadlock. Yes, I understand the VFS deadlock. I see, I didn't realize the call was against the directory, thank you for explaining. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111117183642.GY1455>