From owner-svn-src-head@FreeBSD.ORG Sun Sep 12 21:02:24 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAAC7106566B; Sun, 12 Sep 2010 21:02:24 +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 B09848FC0A; Sun, 12 Sep 2010 21:02:24 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 57F2346B0C; Sun, 12 Sep 2010 17:02:24 -0400 (EDT) Date: Sun, 12 Sep 2010 22:02:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kostik Belousov In-Reply-To: <20100912205311.GG2465@deviant.kiev.zoral.com.ua> Message-ID: References: <201009121906.o8CJ68vQ002600@svn.freebsd.org> <20100912205311.GG2465@deviant.kiev.zoral.com.ua> 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-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 21:02:25 -0000 On Sun, 12 Sep 2010, Kostik Belousov wrote: > 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. Ah, I think I see where my misunderstanding arose: the behavior of kernel process fork is changed as a result of running in a different (specific) context, and hence never acquires the file descriptor lock class? Robert