From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 6 09:25:57 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED24C16B803 for ; Tue, 6 Jun 2006 09:22:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (ll-227.216.82.212.sovam.net.ua [212.82.216.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id D53C843D45 for ; Tue, 6 Jun 2006 09:22:25 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k569N3eG005822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jun 2006 12:23:03 +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.13.6/8.13.6) with ESMTP id k569MD2R071737; Tue, 6 Jun 2006 12:22:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k569MCdq071736; Tue, 6 Jun 2006 12:22:12 +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: Tue, 6 Jun 2006 12:22:12 +0300 From: Konstantin Belousov To: Andrey Simonenko Message-ID: <20060606092212.GB45380@deviant.kiev.zoral.com.ua> References: <20060605110136.GA1348@pm513-1.comsys.ntu-kpi.kiev.ua> <20060605173045.GA45380@deviant.kiev.zoral.com.ua> <20060606082529.GA767@pm513-1.comsys.ntu-kpi.kiev.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline In-Reply-To: <20060606082529.GA767@pm513-1.comsys.ntu-kpi.kiev.ua> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on fw.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: Question about synchronization (nfssvc, vfs_busy) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:25:59 -0000 --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 06, 2006 at 11:25:29AM +0300, Andrey Simonenko wrote: > On Mon, Jun 05, 2006 at 08:30:45PM +0300, Konstantin Belousov wrote: > > On Mon, Jun 05, 2006 at 02:01:36PM +0300, Andrey Simonenko wrote: > > > 2. > > >=20 > > > If vfs_busy() is called without LK_NOWAIT flag, then it can sleep > > > if a filesystem is being unmounted. At some point unmount() will > > If vfs_busy() is called without LK_NOWAIT and fs is being unmounted, > > then vfs_busy returns with ENOENT error, isn't it ? > >=20 >=20 > Yes, it returns ENOENT, but before this event vfs_busy() sets MNTK_MWAIT > flag and sleeps on mount point address. When vfs_mount_destroy() sees > MNTK_MWAIT, it wakes up a thread which sleeps in vfs_busy(). Since > vfs_busy() and vfs_mount_destroy() are active only if MNT_MTX(mp) is > acquired, vfs_mount_destroy() continues own execution, deallocating > mount point, so mutex address passed to msleep() in vfs_busy() is not > valid any more. Are you concerned about invocation of vfs_mount_destroy() at line 1224 of vfs_mount.c, in dounmount ?=20 Do you experience problems (panics, etc) caused by this issue ? It seems that this scenario is impossible for some reasons that are external to vfs_busy, because dounmount() aquires exclusive lock on the vnode covered by mount point. As far as I see, all invocations of vfs_busy() without LK_NOWAIT flag are done while holding at least shared lock on that vnode. See, for instance, fchdir() from vfs_syscalls.c. --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEhUlDC3+MBN1Mb4gRAuGbAKCOc65xHM6O8ae7ovh7r+moQJI4cwCgglMg cwK4VUKBGqbIZiabcx2WHVg= =aGaX -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU--