From owner-svn-src-all@FreeBSD.ORG Sun Sep 12 20:41:47 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A885106564A; Sun, 12 Sep 2010 20:41:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 622A98FC0C; Sun, 12 Sep 2010 20:41:47 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id E477946B8D; Sun, 12 Sep 2010 16:41:46 -0400 (EDT) Date: Sun, 12 Sep 2010 21:41:46 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Konstantin Belousov In-Reply-To: <201009121906.o8CJ68vQ002600@svn.freebsd.org> Message-ID: References: <201009121906.o8CJ68vQ002600@svn.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r212506 - head/sys/nfsclient X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 20:41:47 -0000 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