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