Date: Sun, 12 Sep 2010 21:41:46 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Konstantin Belousov <kib@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: <alpine.BSF.2.00.1009122140040.52130@fledge.watson.org> In-Reply-To: <201009121906.o8CJ68vQ002600@svn.freebsd.org> References: <201009121906.o8CJ68vQ002600@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1009122140040.52130>