locking questions (regarding file systems)
Eric Anderson
anderson at centtech.com
Thu Aug 3 04:52:13 UTC 2006
On 08/02/06 23:08, Eric Anderson wrote:
> On 08/02/06 14:34, R. B. Riddick wrote:
>> --- Eric Anderson <anderson at 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?
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.
------------------------------------------------------------------------
More information about the freebsd-fs
mailing list