linux.git/fs/fscache, branch v4.0

fs/fscache/object-list.c: use __seq_open_private()

2014-10-13T16:52:21+00:00

Reduce boilerplate code by using __seq_open_private() instead of seq_open()
in fscache_objlist_open().

Signed-off-by: Rob Jones 
Signed-off-by: David Howells 
Acked-by: Steve Dickson

FS-Cache: refcount becomes corrupt under vma pressure.

2014-09-17T21:41:40+00:00

In rare cases under heavy VMA pressure the ref count for a fscache cookie
becomes corrupt. In this case we decrement ref count even if we fail before
incrementing the refcount.

FS-Cache: Assertion failed bnode-eca5f9c6/syslog
0 > 0 is false
------------[ cut here ]------------
kernel BUG at fs/fscache/cookie.c:519!
invalid opcode: 0000 [#1] SMP
Call Trace:
[] __fscache_relinquish_cookie+0x50/0x220 [fscache]
[] ceph_fscache_unregister_inode_cookie+0x3e/0x50 [ceph]
[] ceph_destroy_inode+0x33/0x200 [ceph]
[] ? __fsnotify_inode_delete+0xe/0x10
[] destroy_inode+0x3c/0x70
[] evict+0x111/0x180
[] iput+0x103/0x190
[] __dentry_kill+0x1c8/0x220
[] shrink_dentry_list+0xf1/0x250
[] prune_dcache_sb+0x4c/0x60
[] super_cache_scan+0xff/0x170
[] shrink_slab_node+0x140/0x2c0
[] shrink_slab+0x8a/0x130
[] balance_pgdat+0x3e2/0x5d0
[] kswapd+0x16a/0x4a0
[] ? __wake_up_sync+0x20/0x20
[] ? balance_pgdat+0x5d0/0x5d0
[] kthread+0xc9/0xe0
[] ? ftrace_raw_event_xen_mmu_release_ptpage+0x70/0x90
[] ? flush_kthread_worker+0xb0/0xb0
[] ret_from_fork+0x7c/0xb0
[] ? flush_kthread_worker+0xb0/0xb0
RIP [] __fscache_disable_cookie+0x1db/0x210 [fscache]
RSP 
---[ end trace 254d0d7c74a01f25 ]---

Signed-off-by: Milosz Tanski 
Signed-off-by: David Howells

FS-Cache: Reduce cookie ref count if submit fails.

2014-08-27T14:29:34+00:00

I've been seeing issues with disposing cookies under vma pressure. The symptom
is that the refcount gets out of sync. In this case we fail to decrement the
refcount if submit fails. I found this while auditing the error in and around
cookie operations.

Signed-off-by: Milosz Tanski 
Signed-off-by: David Howells

FS-Cache: Timeout for releasepage()

2014-08-27T14:24:06+00:00

This is meant to avoid a recusive hang caused by underlying filesystem trying
to grab a free page and causing a write-out.

INFO: task kworker/u30:7:28375 blocked for more than 120 seconds.
      Not tainted 3.15.0-virtual #74
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u30:7   D 0000000000000000     0 28375      2 0x00000000
Workqueue: fscache_operation fscache_op_work_func [fscache]
 ffff88000b147148 0000000000000046 0000000000000000 ffff88000b1471c8
 ffff8807aa031820 0000000000014040 ffff88000b147fd8 0000000000014040
 ffff880f0c50c860 ffff8807aa031820 ffff88000b147158 ffff88007be59cd0
Call Trace:
 [] schedule+0x29/0x70
 [] __fscache_wait_on_page_write+0x55/0x90 [fscache]
 [] ? __wake_up_sync+0x20/0x20
 [] __fscache_maybe_release_page+0x65/0x1e0 [fscache]
 [] ceph_releasepage+0x83/0x100 [ceph]
 [] ? anon_vma_fork+0x130/0x130
 [] try_to_release_page+0x32/0x50
 [] shrink_page_list+0x7e6/0x9d0
 [] ? isolate_lru_pages.isra.73+0x78/0x1e0
 [] shrink_inactive_list+0x252/0x4c0
 [] shrink_lruvec+0x3e1/0x670
 [] shrink_zone+0x3f/0x110
 [] do_try_to_free_pages+0x1d6/0x450
 [] ? zone_statistics+0x99/0xc0
 [] try_to_free_pages+0xc4/0x180
 [] __alloc_pages_nodemask+0x6b2/0xa60
 [] ? __find_get_block+0xbe/0x250
 [] ? wake_up_bit+0x2e/0x40
 [] alloc_pages_current+0xb3/0x180
 [] __page_cache_alloc+0xb7/0xd0
 [] grab_cache_page_write_begin+0x7c/0xe0
 [] ? ext4_mark_inode_dirty+0x82/0x220
 [] ext4_da_write_begin+0x89/0x2d0
 [] generic_perform_write+0xbe/0x1d0
 [] ? update_time+0x81/0xc0
 [] ? mnt_clone_write+0x12/0x30
 [] __generic_file_aio_write+0x1ce/0x3f0
 [] generic_file_aio_write+0x5e/0xe0
 [] ext4_file_write+0x9f/0x410
 [] ? ext4_file_open+0x66/0x180
 [] do_sync_write+0x5a/0x90
 [] cachefiles_write_page+0x149/0x430 [cachefiles]
 [] ? radix_tree_gang_lookup_tag+0x89/0xd0
 [] fscache_write_op+0x222/0x3b0 [fscache]
 [] fscache_op_work_func+0x3a/0x100 [fscache]
 [] process_one_work+0x179/0x4a0
 [] worker_thread+0x11b/0x370
 [] ? manage_workers.isra.21+0x2e0/0x2e0
 [] kthread+0xc9/0xe0
 [] ? ftrace_raw_event_xen_mmu_release_ptpage+0x70/0x90
 [] ? flush_kthread_worker+0xb0/0xb0
 [] ret_from_fork+0x7c/0xb0
 [] ? flush_kthread_worker+0xb0/0xb0

Signed-off-by: Milosz Tanski 
Signed-off-by: David Howells

fs/fscache: make ctl_table static

2014-08-07T01:01:12+00:00

fscache_sysctls and fscache_sysctls_root are only used in main.c

Signed-off-by: Fabian Frederick 
Cc: David Howells 
Cc: Joe Perches 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

sched: Remove proliferation of wait_on_bit() action functions

2014-07-16T13:10:39+00:00

The current "wait_on_bit" interface requires an 'action'
function to be provided which does the actual waiting.
There are over 20 such functions, many of them identical.
Most cases can be satisfied by one of just two functions, one
which uses io_schedule() and one which just uses schedule().

So:
 Rename wait_on_bit and        wait_on_bit_lock to
        wait_on_bit_action and wait_on_bit_lock_action
 to make it explicit that they need an action function.

 Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io
 which are *not* given an action function but implicitly use
 a standard one.
 The decision to error-out if a signal is pending is now made
 based on the 'mode' argument rather than being encoded in the action
 function.

 All instances of the old wait_on_bit and wait_on_bit_lock which
 can use the new version have been changed accordingly and their
 action functions have been discarded.
 wait_on_bit{_lock} does not return any specific error code in the
 event of a signal so the caller must check for non-zero and
 interpolate their own error code as appropriate.

The wait_on_bit() call in __fscache_wait_on_invalidate() was
ambiguous as it specified TASK_UNINTERRUPTIBLE but used
fscache_wait_bit_interruptible as an action function.
David Howells confirms this should be uniformly
"uninterruptible"

The main remaining user of wait_on_bit{,_lock}_action is NFS
which needs to use a freezer-aware schedule() call.

A comment in fs/gfs2/glock.c notes that having multiple 'action'
functions is useful as they display differently in the 'wchan'
field of 'ps'. (and /proc/$PID/wchan).
As the new bit_wait{,_io} functions are tagged "__sched", they
will not show up at all, but something higher in the stack.  So
the distinction will still be visible, only with different
function names (gds2_glock_wait versus gfs2_glock_dq_wait in the
gfs2/glock.c case).

Since first version of this patch (against 3.15) two new action
functions appeared, on in NFS and one in CIFS.  CIFS also now
uses an action function that makes the same freezer aware
schedule call as NFS.

Signed-off-by: NeilBrown 
Acked-by: David Howells  (fscache, keys)
Acked-by: Steven Whitehouse  (gfs2)
Acked-by: Peter Zijlstra 
Cc: Oleg Nesterov 
Cc: Steve French 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/20140707051603.28027.72349.stgit@notabene.brown
Signed-off-by: Ingo Molnar

fscache: convert use of typedef ctl_table to struct ctl_table

2014-06-06T23:08:16+00:00

This typedef is unnecessary and should just be removed.

Signed-off-by: Joe Perches 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/fscache: replace seq_printf by seq_puts

2014-06-04T23:53:52+00:00

Replace seq_printf where possible + coalesce formats from 2 existing
seq_puts

Signed-off-by: Fabian Frederick 
Cc: David Howells 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/fscache: convert printk to pr_foo()

2014-06-04T23:53:51+00:00

All printk converted to pr_foo() except internal.h: printk(KERN_DEBUG

Coalesce formats.

Add pr_fmt

Signed-off-by: Fabian Frederick 
Cc: David Howells 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

FS-Cache: Handle removal of unadded object to the fscache_object_list rb tree

2014-02-17T21:47:35+00:00

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 
Signed-off-by: David Howells 
Tested-by: (a customer of) NeilBrown 
Signed-off-by: Linus Torvalds