Date: Sun, 12 Sep 2010 23:53:11 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Robert Watson <rwatson@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r212506 - head/sys/nfsclient Message-ID: <20100912205311.GG2465@deviant.kiev.zoral.com.ua> In-Reply-To: <alpine.BSF.2.00.1009122140040.52130@fledge.watson.org> References: <201009121906.o8CJ68vQ002600@svn.freebsd.org> <alpine.BSF.2.00.1009122140040.52130@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Sun, Sep 12, 2010 at 09:41:46PM +0100, Robert Watson wrote: > > On Sun, 12 Sep 2010, Konstantin Belousov wrote: > > > Do not fork nfsiod directly from the vop methods. This causes LORs between > > vnode lock and several locks needed during fork, like fd lock. > > > > Instead, schedule the task to be executed in the taskqueue context. We > > still waiting for the fork to finish, but the context of the thread > > executing the task does not make real LORs with our vnode lock. > > Does this actually functionally improve things, or is all this complexity > about suppressing the lock order reversal? If we're waiting synchronously > for the other thread to launch from the task queue, then the lock order > reversal still exists, it's just not visible to WITNESS... If we had a > static analysis tool that could run on lock and sleep/wakeup traces, it > would still show a deadlock opportunity. As I said in commit message, the deadlock should be fixed, because the taskq thread is executed in the kernel process that should even not have file descriptors at all. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyNPbYACgkQC3+MBN1Mb4horACdEfBPBECx7PKyITCdgySMJXtg i+8AoMowsZKPz3IJIAjmZin4Ba6dD3YN =Qiid -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100912205311.GG2465>