From owner-svn-src-head@FreeBSD.ORG Sun Sep 12 21:12:13 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 81F9E106566C; Sun, 12 Sep 2010 21:12:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1C30D8FC15; Sun, 12 Sep 2010 21:12:12 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o8CLC9Pj014641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Sep 2010 00:12:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o8CLC9uV010838; Mon, 13 Sep 2010 00:12:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o8CLC9NP010837; Mon, 13 Sep 2010 00:12:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 13 Sep 2010 00:12:09 +0300 From: Kostik Belousov To: Robert Watson Message-ID: <20100912211209.GH2465@deviant.kiev.zoral.com.ua> References: <201009121906.o8CJ68vQ002600@svn.freebsd.org> <20100912205311.GG2465@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sjel/IY1pyoUgMMX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua 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:12:13 -0000 --sjel/IY1pyoUgMMX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 12, 2010 at 10:02:24PM +0100, Robert Watson wrote: >=20 > On Sun, 12 Sep 2010, Kostik Belousov wrote: >=20 > >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=20 > >>>between vnode lock and several locks needed during fork, like fd lock. > >>> > >>>Instead, schedule the task to be executed in the taskqueue context. We= =20 > >>>still waiting for the fork to finish, but the context of the thread=20 > >>>executing the task does not make real LORs with our vnode lock. > >> > >>Does this actually functionally improve things, or is all this complexi= ty=20 > >>about suppressing the lock order reversal? If we're waiting=20 > >>synchronously for the other thread to launch from the task queue, then= =20 > >>the lock order reversal still exists, it's just not visible to WITNESS.= ..=20 > >>If we had a static analysis tool that could run on lock and sleep/wakeu= p=20 > >>traces, it would still show a deadlock opportunity. > > > >As I said in commit message, the deadlock should be fixed, because the= =20 > >taskq thread is executed in the kernel process that should even not have= =20 > >file descriptors at all. >=20 > Ah, I think I see where my misunderstanding arose: the behavior of kernel= =20 > process fork is changed as a result of running in a different (specific)= =20 > context, and hence never acquires the file descriptor lock class? The original code created nfsiod by forking inside the vop, that happens to execute in the context of whatever user process that initiated the operation. Taskqueue is executing in the intr process context, that should not have file descriptors allocated at all. Actually, even if the intr process had fd allocated, then it still should not lock the table. --sjel/IY1pyoUgMMX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyNQicACgkQC3+MBN1Mb4h+7wCgkHSYVd8gyeqpVPKMmgGMQHMK slMAnjF43/L7m0JmEhk3EDZmYurrEz8L =zw7A -----END PGP SIGNATURE----- --sjel/IY1pyoUgMMX--