Date: Wed, 02 Aug 2006 14:40:08 -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: <44D0FF98.3040701@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 never get to a second unmount, because I can't mount or mdconfig -d the device after the first mount. > 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? I don't know - how can I check? > 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 > functions? Good idea - I'll look into that.. 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?44D0FF98.3040701>