Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

CacheFiles: Fix a race in cachefiles_delete_object() vs rename

Browse source 
cachefiles_delete_object() can race with rename.  It gets the parent directory
of the object it's asked to delete, then locks it - but rename may have changed
the object's parent between the get and the completion of the lock.

However, if such a circumstance is detected, we abandon our attempt to delete
the object - since it's no longer in the index key path, it won't be seen
again by lookups of that key.  The assumption is that cachefilesd may have
culled it by renaming it to the graveyard for later destruction.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
This commit is contained in:
David Howells 2010-02-19 18:14:21 +00:00 committed by Al Viro
parent aeaa5ccd64
commit 8f9941aecc
1 changed files with 11 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
fs/cachefiles/namei.c
View file

@ -348,7 +348,17 @@ int cachefiles_delete_object(struct cachefiles_cache *cache,
dir = dget_parent(object->dentry);
mutex_lock_nested(&dir->d_inode->i_mutex, I_MUTEX_PARENT);
ret = cachefiles_bury_object(cache, dir, object->dentry);
/* we need to check that our parent is _still_ our parent - it may have
* been renamed */
if (dir == object->dentry->d_parent) {
ret = cachefiles_bury_object(cache, dir, object->dentry);
} else {
/* it got moved, presumably by cachefilesd culling it, so it's
* no longer in the key path and we can ignore it */
mutex_unlock(&dir->d_inode->i_mutex);
ret = 0;
}
dput(dir);
_leave(" = %d", ret);