FS-Cache: Handle read request vs lookup, creation or other cache failure
authorDavid Howells <dhowells@redhat.com>
Thu, 19 Nov 2009 18:11:32 +0000 (18:11 +0000)
committerDavid Howells <dhowells@redhat.com>
Thu, 19 Nov 2009 18:11:32 +0000 (18:11 +0000)
commite3d4d28b1c8cc7c26536a50b43d86ccd39878550
tree23f6dacd5ffdf6c6d01c411517855a41405381b9
parent285e728b0ac55b53a673114096168d6f74930167
FS-Cache: Handle read request vs lookup, creation or other cache failure

FS-Cache doesn't correctly handle the netfs requesting a read from the cache
on an object that failed or was withdrawn by the cache.  A trace similar to
the following might be seen:

CacheFiles: Lookup failed error -105
[exe   ] unexpected submission OP165afe [OBJ6cac OBJECT_LC_DYING]
[exe   ] objstate=OBJECT_LC_DYING [OBJECT_LC_DYING]
[exe   ] objflags=0
[exe   ] objevent=9 [fffffffffffffffb]
[exe   ] ops=0 inp=0 exc=0
Pid: 6970, comm: exe Not tainted 2.6.32-rc6-cachefs #50
Call Trace:
 [<ffffffffa0076477>] fscache_submit_op+0x3ff/0x45a [fscache]
 [<ffffffffa0077997>] __fscache_read_or_alloc_pages+0x187/0x3c4 [fscache]
 [<ffffffffa00b6480>] ? nfs_readpage_from_fscache_complete+0x0/0x66 [nfs]
 [<ffffffffa00b6388>] __nfs_readpages_from_fscache+0x7e/0x176 [nfs]
 [<ffffffff8108e483>] ? __alloc_pages_nodemask+0x11c/0x5cf
 [<ffffffffa009d796>] nfs_readpages+0x114/0x1d7 [nfs]
 [<ffffffff81090314>] __do_page_cache_readahead+0x15f/0x1ec
 [<ffffffff81090228>] ? __do_page_cache_readahead+0x73/0x1ec
 [<ffffffff810903bd>] ra_submit+0x1c/0x20
 [<ffffffff810906bb>] ondemand_readahead+0x227/0x23a
 [<ffffffff81090762>] page_cache_sync_readahead+0x17/0x19
 [<ffffffff8108a99e>] generic_file_aio_read+0x236/0x5a0
 [<ffffffffa00937bd>] nfs_file_read+0xe4/0xf3 [nfs]
 [<ffffffff810b2fa2>] do_sync_read+0xe3/0x120
 [<ffffffff81354cc3>] ? _spin_unlock_irq+0x2b/0x31
 [<ffffffff8104c0f1>] ? autoremove_wake_function+0x0/0x34
 [<ffffffff811848e5>] ? selinux_file_permission+0x5d/0x10f
 [<ffffffff81352bdb>] ? thread_return+0x3e/0x101
 [<ffffffff8117d7b0>] ? security_file_permission+0x11/0x13
 [<ffffffff810b3b06>] vfs_read+0xaa/0x16f
 [<ffffffff81058df0>] ? trace_hardirqs_on_caller+0x10c/0x130
 [<ffffffff810b3c84>] sys_read+0x45/0x6c
 [<ffffffff8100ae2b>] system_call_fastpath+0x16/0x1b

The object state might also be OBJECT_DYING or OBJECT_WITHDRAWING.

This should be handled by simply rejecting the new operation with ENOBUFS.
There's no need to log an error for it.  Events of this type now appear in the
stats file under Ops:rej.

Signed-off-by: David Howells <dhowells@redhat.com>
Documentation/filesystems/caching/fscache.txt
fs/fscache/internal.h
fs/fscache/operation.c
fs/fscache/stats.c