* Reverted r22315 as far as free_vnode() is concerned: removing the

vnode from the hash before putting it caused all sorts of problems.
* For example, BFS would trim its preallocations when the vnode is put;
  if someone would read that same vnode after it had been removed, but
  before BFS could trim it, it would read the old vnode which still 
  seemed to own the blocks which would subsequently be freed.
* This fixes bug #1914, and should also fix bug #1956.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24607 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Axel Dörfler 2008-03-27 09:48:33 +00:00
parent 14438ad555
commit 9e79133f4d
1 changed files with 6 additions and 6 deletions

View File

@ -691,12 +691,6 @@ free_vnode(struct vnode *vnode, bool reenter)
// count, so that it will neither become negative nor 0.
vnode->ref_count = 2;
// The file system has removed the resources of the vnode now, so we can
// make it available again (and remove the busy vnode from the hash)
mutex_lock(&sVnodeMutex);
hash_remove(sVnodeTable, vnode);
mutex_unlock(&sVnodeMutex);
// TODO: Usually, when the vnode is unreferenced, no one can get hold of the
// cache either (i.e. no one can get a cache reference while we're deleting
// the vnode).. This is, however, not the case for the page daemon. It gets
@ -713,6 +707,12 @@ free_vnode(struct vnode *vnode, bool reenter)
}
}
// The file system has removed the resources of the vnode now, so we can
// make it available again (and remove the busy vnode from the hash)
mutex_lock(&sVnodeMutex);
hash_remove(sVnodeTable, vnode);
mutex_unlock(&sVnodeMutex);
// if we have a vm_cache attached, remove it
if (vnode->cache)
vm_cache_release_ref(vnode->cache);