![]() 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> |
||
---|---|---|
.. | ||
bind.c | ||
daemon.c | ||
interface.c | ||
internal.h | ||
Kconfig | ||
key.c | ||
main.c | ||
Makefile | ||
namei.c | ||
proc.c | ||
rdwr.c | ||
security.c | ||
xattr.c |