Date: Wed, 02 Aug 2006 23:08:15 -0500 From: Eric Anderson <anderson@centtech.com> To: "R. B. Riddick" <arne_woerner@yahoo.com> Cc: freebsd-fs@freebsd.org Subject: Re: locking questions (regarding file systems) Message-ID: <44D176AF.8020300@centtech.com> In-Reply-To: <20060802193408.47760.qmail@web30301.mail.mud.yahoo.com> References: <20060802193408.47760.qmail@web30301.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/02/06 14:34, R. B. Riddick wrote: > --- Eric Anderson <anderson@centtech.com> 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? Thanks! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44D176AF.8020300>