Date: Mon, 13 Sep 2010 00:12:09 +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: <20100912211209.GH2465@deviant.kiev.zoral.com.ua> In-Reply-To: <alpine.BSF.2.00.1009122158380.52130@fledge.watson.org> References: <201009121906.o8CJ68vQ002600@svn.freebsd.org> <alpine.BSF.2.00.1009122140040.52130@fledge.watson.org> <20100912205311.GG2465@deviant.kiev.zoral.com.ua> <alpine.BSF.2.00.1009122158380.52130@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100912211209.GH2465>