From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 6 08:43:18 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 1B6B116A6FB for ; Tue, 6 Jun 2006 08:25:38 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 016E743D49 for ; Tue, 6 Jun 2006 08:25:32 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm513-1.comsys.ntu-kpi.kiev.ua (pm513-1.comsys.ntu-kpi.kiev.ua [10.18.52.101]) (authenticated bits=0) by comsys.ntu-kpi.kiev.ua (8.13.6/8.13.6) with ESMTP id k568QYvk058152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Jun 2006 11:26:34 +0300 (EEST) Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 0EC165C024; Tue, 6 Jun 2006 11:25:30 +0300 (EEST) Date: Tue, 6 Jun 2006 11:25:29 +0300 From: Andrey Simonenko To: Konstantin Belousov Message-ID: <20060606082529.GA767@pm513-1.comsys.ntu-kpi.kiev.ua> References: <20060605110136.GA1348@pm513-1.comsys.ntu-kpi.kiev.ua> <20060605173045.GA45380@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060605173045.GA45380@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=unavailable version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/1456/Thu May 11 08:57:31 2006 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean 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 08:43:20 -0000 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. > > > > 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 ? > 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. > > reach vfs_mount_destroy() and since there is one ref from vfs_busy() > > it will sleep 3 seconds and will notice MNTK_MWAIT flag and wake up > > a process, which is sleeping in vfs_busy(). How woken up process > > can work with mount structure in vfs_busy() after wakeup(), which > > could be already deallocated in vfs_mount_destroy()? > vfs_busy() internally increases the ref count for mount point, so, it cannot > be taken from under it (look for MNT_REF/MNT_REL). Simultameous entrance > into the code in question in vfs_busy/vfs_mount_destroy is protected > by mnt_mtx (MNT_ILOCK/MNT_IUNLOCK). > > A reference counter is increased, but in vfs_mount_destroy() in first for() (mnt_ref != 0) is checked only 3 seconds, then debug message is outputted. Let me ask in other words, how vfs_ref() guarantees that unmount() in vfs_mount_destroy() will not deallocate a mount point (see checks in first for() loop, also assume that mnt_holdcnt, mnt_writeopcount and mnt_secondary_writes are equal to zero)? I also wanted to ask similar question about vfs_getvfs(), but as I understand in CURRENT it was corrected.