summaryrefslogtreecommitdiff
path: root/fs/ecryptfs
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2014-02-17 15:01:47 +0000
committerLinus Torvalds <torvalds@linux-foundation.org>2014-02-17 13:47:35 -0800
commit7026f1929e18921fd67bf478f475a8fdfdff16ae (patch)
treebddfd52b6d380a6620b6fd0703ae6230168d3a6d /fs/ecryptfs
parent416e2abd925d0f41dc877d1fe01489d79bdecf4c (diff)
downloadlinux-stable-7026f1929e18921fd67bf478f475a8fdfdff16ae.tar.gz
linux-stable-7026f1929e18921fd67bf478f475a8fdfdff16ae.tar.bz2
linux-stable-7026f1929e18921fd67bf478f475a8fdfdff16ae.zip
FS-Cache: Handle removal of unadded object to the fscache_object_list rb tree
When FS-Cache allocates an object, the following sequence of events can occur: -->fscache_alloc_object() -->cachefiles_alloc_object() [via cache->ops->alloc_object] <--[returns new object] -->fscache_attach_object() <--[failed] -->cachefiles_put_object() [via cache->ops->put_object] -->fscache_object_destroy() -->fscache_objlist_remove() -->rb_erase() to remove the object from fscache_object_list. resulting in a crash in the rbtree code. The problem is that the object is only added to fscache_object_list on the success path of fscache_attach_object() where it calls fscache_objlist_add(). So if fscache_attach_object() fails, the object won't have been added to the objlist rbtree. We do, however, unconditionally try to remove the object from the tree. Thanks to NeilBrown for finding this and suggesting this solution. Reported-by: NeilBrown <neilb@suse.de> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: (a customer of) NeilBrown <neilb@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/ecryptfs')
0 files changed, 0 insertions, 0 deletions