kernel.git/fs/fscache/page.c, branch linux-3.17.y

FS-Cache: refcount becomes corrupt under vma pressure.

2014-09-17T21:41:40Z

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: Timeout for releasepage()

2014-08-27T14:24:06Z

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

sched: Remove proliferation of wait_on_bit() action functions

2014-07-16T13:10:39Z

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

fs/fscache: convert printk to pr_foo()

2014-06-04T23:53:51Z

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: Provide the ability to enable/disable cookies

2013-09-27T17:40:25Z

Provide the ability to enable and disable fscache cookies. A disabled cookie will reject or ignore further requests to: Acquire a child cookie Invalidate and update backing objects Check the consistency of a backing object Allocate storage for backing page Read backing pages Write to backing pages but still allows: Checks/waits on the completion of already in-progress objects Uncaching of pages Relinquishment of cookies Two new operations are provided: (1) Disable a cookie: void fscache_disable_cookie(struct fscache_cookie *cookie, bool invalidate); If the cookie is not already disabled, this locks the cookie against other dis/enablement ops, marks the cookie as being disabled, discards or invalidates any backing objects and waits for cessation of activity on any associated object. This is a wrapper around a chunk split out of fscache_relinquish_cookie(), but it reinitialises the cookie such that it can be reenabled. All possible failures are handled internally. The caller should consider calling fscache_uncache_all_inode_pages() afterwards to make sure all page markings are cleared up. (2) Enable a cookie: void fscache_enable_cookie(struct fscache_cookie *cookie, bool (*can_enable)(void *data), void *data) If the cookie is not already enabled, this locks the cookie against other dis/enablement ops, invokes can_enable() and, if the cookie is not an index cookie, will begin the procedure of acquiring backing objects. The optional can_enable() function is passed the data argument and returns a ruling as to whether or not enablement should actually be permitted to begin. All possible failures are handled internally. The cookie will only be marked as enabled if provisional backing objects are allocated. A later patch will introduce these to NFS. Cookie enablement during nfs_open() is then contingent on i_writecount <= 0. can_enable() checks for a race between open(O_RDONLY) and open(O_WRONLY/O_RDWR). This simplifies NFS's cookie handling and allows us to get rid of open(O_RDONLY) accidentally introducing caching to an inode that's open for writing already. One operation has its API modified: (3) Acquire a cookie. struct fscache_cookie *fscache_acquire_cookie( struct fscache_cookie *parent, const struct fscache_cookie_def *def, void *netfs_data, bool enable); This now has an additional argument that indicates whether the requested cookie should be enabled by default. It doesn't need the can_enable() function because the caller must prevent multiple calls for the same netfs object and it doesn't need to take the enablement lock because no one else can get at the cookie before this returns. Signed-off-by: David Howells

FS-Cache: Add use/unuse/wake cookie wrappers

2013-09-27T17:40:25Z

Add wrapper functions for dealing with cookie->n_active: (*) __fscache_use_cookie() to increment it. (*) __fscache_unuse_cookie() to decrement and test against zero. (*) __fscache_wake_unused_cookie() to wake up anyone waiting for it to reach zero. The second and third are split so that the third can be done after cookie->lock has been released in case the waiter wakes up whilst we're still holding it and tries to get it. We will need to wake-on-zero once the cookie disablement patch is applied because it will then be possible to see n_active become zero without the cookie being relinquished. Also move the cookie usement out of fscache_attr_changed_op() and into fscache_attr_changed() and the operation struct so that cookie disablement will be able to track it. Whilst we're at it, only increment n_active if we're about to do fscache_submit_op() so that we don't have to deal with undoing it if anything earlier fails. Possibly this should be moved into fscache_submit_op() which could look at FSCACHE_OP_UNUSE_COOKIE. Signed-off-by: David Howells

lib/radix-tree.c: make radix_tree_node_alloc() work correctly within interrupt

2013-09-11T22:59:36Z

With users of radix_tree_preload() run from interrupt (block/blk-ioc.c is one such possible user), the following race can happen: radix_tree_preload() ... radix_tree_insert() radix_tree_node_alloc() if (rtp->nr) { ret = rtp->nodes[rtp->nr - 1]; ... radix_tree_preload() ... radix_tree_insert() radix_tree_node_alloc() if (rtp->nr) { ret = rtp->nodes[rtp->nr - 1]; And we give out one radix tree node twice. That clearly results in radix tree corruption with different results (usually OOPS) depending on which two users of radix tree race. We fix the problem by making radix_tree_node_alloc() always allocate fresh radix tree nodes when in interrupt. Using preloading when in interrupt doesn't make sense since all the allocations have to be atomic anyway and we cannot steal nodes from process-context users because some users rely on radix_tree_insert() succeeding after radix_tree_preload(). in_interrupt() check is somewhat ugly but we cannot simply key off passed gfp_mask as that is acquired from root_gfp_mask() and thus the same for all preload users. Another part of the fix is to avoid node preallocation in radix_tree_preload() when passed gfp_mask doesn't allow waiting. Again, preallocation in such case doesn't make sense and when preallocation would happen in interrupt we could possibly leak some allocated nodes. However, some users of radix_tree_preload() require following radix_tree_insert() to succeed. To avoid unexpected effects for these users, radix_tree_preload() only warns if passed gfp mask doesn't allow waiting and we provide a new function radix_tree_maybe_preload() for those users which get different gfp mask from different call sites and which are prepared to handle radix_tree_insert() failure. Signed-off-by: Jan Kara Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fscache: Netfs function for cleanup post readpages

2013-09-06T08:17:30Z

Currently the fscache code expect the netfs to call fscache_readpages_or_alloc inside the aops readpages callback. It marks all the pages in the list provided by readahead with PG_private_2. In the cases that the netfs fails to read all the pages (which is legal) it ends up returning to the readahead and triggering a BUG. This happens because the page list still contains marked pages. This patch implements a simple fscache_readpages_cancel function that the netfs should call before returning from readpages. It will revoke the pages from the underlying cache backend and unmark them. The problem was originally worked out in the Ceph devel tree, but it also occurs in CIFS. It appears that NFS, AFS and 9P are okay as read_cache_pages() will clean up the unprocessed pages in the case of an error. This can be used to address the following oops: [12410647.597278] BUG: Bad page state in process petabucket pfn:3d504e [12410647.597292] page:ffffea000f541380 count:0 mapcount:0 mapping: (null) index:0x0 [12410647.597298] page flags: 0x200000000001000(private_2) ... [12410647.597334] Call Trace: [12410647.597345] [] dump_stack+0x19/0x1b [12410647.597356] [] bad_page+0xc7/0x120 [12410647.597359] [] free_pages_prepare+0x10e/0x120 [12410647.597361] [] free_hot_cold_page+0x40/0x170 [12410647.597363] [] __put_single_page+0x27/0x30 [12410647.597365] [] put_page+0x25/0x40 [12410647.597376] [] ceph_readpages+0x2e9/0x6e0 [ceph] [12410647.597379] [] __do_page_cache_readahead+0x1af/0x260 [12410647.597382] [] ra_submit+0x21/0x30 [12410647.597384] [] filemap_fault+0x254/0x490 [12410647.597387] [] __do_fault+0x6f/0x4e0 [12410647.597391] [] ? __switch_to+0x16d/0x4a0 [12410647.597395] [] ? finish_task_switch+0x5a/0xc0 [12410647.597398] [] handle_pte_fault+0xf6/0x930 [12410647.597401] [] ? pte_mfn_to_pfn+0x93/0x110 [12410647.597403] [] ? xen_pmd_val+0xe/0x10 [12410647.597405] [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e [12410647.597407] [] handle_mm_fault+0x251/0x370 [12410647.597411] [] ? call_rwsem_down_read_failed+0x14/0x30 [12410647.597414] [] __do_page_fault+0x1aa/0x550 [12410647.597418] [] ? up_write+0x1d/0x20 [12410647.597422] [] ? vm_mmap_pgoff+0xbc/0xe0 [12410647.597425] [] ? SyS_mmap_pgoff+0xd8/0x240 [12410647.597427] [] do_page_fault+0xe/0x10 [12410647.597431] [] page_fault+0x28/0x30 Signed-off-by: Milosz Tanski Signed-off-by: David Howells

FS-Cache: Add interface to check consistency of a cached object

2013-09-06T08:17:30Z

Extend the fscache netfs API so that the netfs can ask as to whether a cache object is up to date with respect to its corresponding netfs object: int fscache_check_consistency(struct fscache_cookie *cookie) This will call back to the netfs to check whether the auxiliary data associated with a cookie is correct. It returns 0 if it is and -ESTALE if it isn't; it may also return -ENOMEM and -ERESTARTSYS. The backends now have to implement a mandatory operation pointer: int (*check_consistency)(struct fscache_object *object) that corresponds to the above API call. FS-Cache takes care of pinning the object and the cookie in memory and managing this call with respect to the object state. Original-author: Hongyi Jia Signed-off-by: David Howells cc: Hongyi Jia cc: Milosz Tanski

FS-Cache: The retrieval remaining-pages counter needs to be atomic_t

2013-06-19T13:16:47Z

struct fscache_retrieval contains a count of the number of pages that still need some processing (n_pages). This is decremented as the pages are processed. However, this needs to be atomic as fscache_retrieval_complete() (I think) just occasionally may be called from cachefiles_read_backing_file() and cachefiles_read_copier() simultaneously. This happens when an fscache_read_or_alloc_pages() request containing a lot of pages (say a couple of hundred) is being processed. The read on each backing page is dispatched individually because we need to insert a monitor into the waitqueue to catch when the read completes. However, under low-memory conditions, we might be forced to wait in the allocator - and this gives the I/O on the backing page a chance to complete first. When the I/O completes, fscache_enqueue_retrieval() chucks the retrieval onto the workqueue without waiting for the operation to finish the initial I/O dispatch (we want to release any pages we can as soon as we can), thus both can end up running simultaneously and potentially attempting to partially complete the retrieval simultaneously (ENOMEM may occur, backing pages may already be in the page cache). This was demonstrated by parallelling the non-atomic counter with an atomic counter and printing both of them when the assertion fails. At this point, the atomic counter has reached zero, but the non-atomic counter has not. To fix this, make the counter an atomic_t. This results in the following bug appearing FS-Cache: Assertion failed 3 == 5 is false ------------[ cut here ]------------ kernel BUG at fs/fscache/operation.c:421! or FS-Cache: Assertion failed 3 == 5 is false ------------[ cut here ]------------ kernel BUG at fs/fscache/operation.c:414! With a backtrace like the following: RIP: 0010:[] fscache_put_operation+0x1ad/0x240 [fscache] Call Trace: [] fscache_retrieval_work+0x55/0x270 [fscache] [] ? fscache_retrieval_work+0x0/0x270 [fscache] [] worker_thread+0x170/0x2a0 [] ? autoremove_wake_function+0x0/0x40 [] ? worker_thread+0x0/0x2a0 [] kthread+0x96/0xa0 [] child_rip+0xa/0x20 [] ? kthread+0x0/0xa0 [] ? child_rip+0x0/0x20 Signed-off-by: David Howells Reviewed-and-tested-By: Milosz Tanski Acked-by: Jeff Layton