From owner-freebsd-fs@FreeBSD.ORG Thu Aug 3 04:52:13 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9C7316A4DA for ; Thu, 3 Aug 2006 04:52:13 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DB5243D53 for ; Thu, 3 Aug 2006 04:52:13 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.24] (andersonbox4.centtech.com [192.168.42.24]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k734qCXq093358; Wed, 2 Aug 2006 23:52:12 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44D1810D.9070808@centtech.com> Date: Wed, 02 Aug 2006 23:52:29 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.5 (X11/20060802) MIME-Version: 1.0 To: Eric Anderson References: <20060802193408.47760.qmail@web30301.mail.mud.yahoo.com> <44D176AF.8020300@centtech.com> In-Reply-To: <44D176AF.8020300@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1634/Wed Aug 2 17:32:49 2006 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org Subject: Re: locking questions (regarding file systems) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 04:52:13 -0000 On 08/02/06 23:08, Eric Anderson wrote: > On 08/02/06 14:34, R. B. Riddick wrote: >> --- Eric Anderson wrote: >>> Here's basically what I do: >>> in the mount function for the FS, I do something like this: >>> >>> DROP_GIANT(); >>> g_topology_lock(); >>> error = g_vfs_open(devvp, &cp, "fsname", 0); >>> g_topology_unlock(); >>> PICKUP_GIANT(); >>> >>> What is needed in my unmount function to release those locks? I've >>> tried some combinations of things, like: >>> >>> DROP_GIANT(); >>> g_topology_lock(); >>> # wedges here >>> g_vfs_close(cp, td); >>> g_topology_unlock(); >>> PICKUP_GIANT(); >>> vrele(devvp); >>> >> So the first un-mount works fine? >> And the second un-mount wedges _before_ g_vfs_close? >> >> I cannot find anything really suspicious in ur code... >> >> Just 2 thoughts: >> >> 1. Do we really hold GIANT, when we mount and un-mount something? >> >> 2. R u sure, that we need vrele()? I mean: Why doesn't g_vfs_close() call >> vrele(), if g_vfs_open() increases that use-count variable? Can u print the >> use-count variable in the beginning and the end of the mount/un-mount > > Looks like after mounting it, the use_count is 1. When unmounting, it > starts at 1, and moves to 0 after doing a vflush, a g_topology_lock, but > before the g_vfs_close. > > Here's the unmount code snippet: > > # here use_count is 1 > error = vflush(mp, 1, flags, td); > if (error) > return (error); > > DROP_GIANT(); > g_topology_lock(); > # this is where the use_count is now zero, and it blocks > g_vfs_close(cp, td); > g_topology_unlock(); > PICKUP_GIANT(); > vrele(devvp); > > Is it blocking because the use_count is already 0? Is the vflush > breaking things? Actually, I misinformed you earlier - I can't actually unmount, because it hangs during the first unmount. It will only unmount successfully if I remove the block above (the DROP_GIANT down to PICKUP_GIANT). Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------