linux/fs/cachefiles, branch v3.18

Merge tag 'fscache-fixes-20141013' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs

2014-10-14T06:40:15Z

Pull fs-cache fixes from David Howells: "Two fixes for bugs in CacheFiles and a cleanup in FS-Cache" * tag 'fscache-fixes-20141013' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: fs/fscache/object-list.c: use __seq_open_private() CacheFiles: Fix incorrect test for in-memory object collision CacheFiles: Handle object being killed before being set up

CacheFiles: Fix incorrect test for in-memory object collision

2014-10-13T16:52:21Z

When CacheFiles cache objects are in use, they have in-memory representations, as defined by the cachefiles_object struct. These are kept in a tree rooted in the cache and indexed by dentry pointer (since there's a unique mapping between object index key and dentry). Collisions can occur between a representation already in the tree and a new representation being set up because it takes time to dispose of an old representation - particularly if it must be unlinked or renamed. When such a collision occurs, cachefiles_mark_object_active() is meant to check to see if the old, already-present representation is in the process of being discarded (ie. FSCACHE_OBJECT_IS_LIVE is not set on it) - and, if so, wait for the representation to be removed (ie. CACHEFILES_OBJECT_ACTIVE is then cleared). However, the test for whether the old representation is still live is checking the new object - which always will be live at this point. This leads to an oops looking like: CacheFiles: Error: Unexpected object collision object: OBJ1b354 objstate=LOOK_UP_OBJECT fl=8 wbusy=2 ev=0[0] ops=0 inp=0 exc=0 parent=ffff88053f5417c0 cookie=ffff880538f202a0 [pr=ffff8805381b7160 nd=ffff880509c6eb78 fl=27] key=[8] '2490000000000000' xobject: OBJ1a600 xobjstate=DROP_OBJECT fl=70 wbusy=2 ev=0[0] xops=0 inp=0 exc=0 xparent=ffff88053f5417c0 xcookie=ffff88050f4cbf70 [pr=ffff8805381b7160 nd= (null) fl=12] ------------[ cut here ]------------ kernel BUG at fs/cachefiles/namei.c:200! ... Workqueue: fscache_object fscache_object_work_func [fscache] ... RIP: ... cachefiles_walk_to_object+0x7ea/0x860 [cachefiles] ... Call Trace: [] ? cachefiles_lookup_object+0x58/0x100 [cachefiles] [] ? fscache_look_up_object+0xb9/0x1d0 [fscache] [] ? fscache_parent_ready+0x2d/0x80 [fscache] [] ? fscache_object_work_func+0x92/0x1f0 [fscache] [] ? process_one_work+0x16b/0x400 [] ? worker_thread+0x116/0x380 [] ? manage_workers.isra.21+0x290/0x290 [] ? kthread+0xbc/0xe0 [] ? flush_kthread_worker+0x80/0x80 [] ? ret_from_fork+0x7c/0xb0 [] ? flush_kthread_worker+0x80/0x80 Reported-by: Manuel Schölling Signed-off-by: David Howells Acked-by: Steve Dickson

cachefiles_write_page(): switch to __kernel_write()

2014-10-09T06:39:05Z

Signed-off-by: Al Viro

CacheFiles: Handle object being killed before being set up

2014-09-30T13:50:28Z

If a cache object gets killed whilst in the process of being set up - for instance if the netfs relinquishes the cookie that the object is associated with - then the object's state machine will transit to the DROP_OBJECT state without necessarily going through the LOOKUP_OBJECT or CREATE_OBJECT states. This is a problem for CacheFiles because cachefiles_drop_object() assumes that object->dentry will be set upon reaching the DROP_OBJECT state and has an ASSERT() to that effect (see the oops below) - but object->dentry doesn't get set until the LOOKUP_OBJECT or CREATE_OBJECT states (and not always then if they fail). To fix this, just make the dentry cleanup in cachefiles_drop_object() conditional on the dentry actually being set and remove the assertion. CacheFiles: Assertion failed ------------[ cut here ]------------ kernel BUG at .../fs/cachefiles/namei.c:425! ... Workqueue: fscache_object fscache_object_work_func [fscache] ... RIP: ... cachefiles_delete_object+0xcd/0x110 [cachefiles] ... Call Trace: [] ? cachefiles_drop_object+0xff/0x130 [cachefiles] [] ? fscache_drop_object+0xd1/0x1d0 [fscache] [] ? fscache_object_work_func+0x87/0x210 [fscache] [] ? process_one_work+0x155/0x450 [] ? worker_thread+0x114/0x370 [] ? manage_workers.isra.21+0x2c0/0x2c0 [] ? kthread+0xbc/0xe0 [] ? flush_kthread_worker+0xa0/0xa0 [] ? ret_from_fork+0x7c/0xb0 [] ? flush_kthread_worker+0xa0/0xa0 Reported-by: Manuel Schölling Signed-off-by: David Howells Acked-by: Steve Dickson

fs/cachefiles: add missing \n to kerror conversions

2014-09-26T15:10:35Z

Commit 0227d6abb378 ("fs/cachefiles: replace kerror by pr_err") didn't include newline featuring in original kerror definition Signed-off-by: Fabian Frederick Reported-by: David Howells Acked-by: David Howells Cc: [3.16.x] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

CacheFiles: Handle rename2

2014-09-17T22:29:53Z

Not all filesystems now provide the rename i_op - ext4 for one - but rather provide the rename2 i_op. CacheFiles checks that the filesystem has rename and so will reject ext4 now with EPERM: CacheFiles: Failed to register: -1 Fix this by checking for rename2 as an alternative. The call to vfs_rename() actually handles selection of the appropriate function, so we needn't worry about that. Turning on debugging shows: [cachef] ==> cachefiles_get_directory(,,cache) [cachef] subdir -> ffff88000b22b778 positive [cachef] <== cachefiles_get_directory() = -1 [check] where -1 is EPERM. Signed-off-by: David Howells

cachefiles: remove two unused pagevecs.

2014-09-17T22:29:50Z

These two have been unused since commit c4d6d8dbf335c7fa47341654a37c53a512b519bb CacheFiles: Fix the marking of cached pages in 3.8. Signed-off-by: NeilBrown Signed-off-by: David Howells

fs/cachefiles: replace kerror by pr_err

2014-06-06T23:08:14Z

Also add pr_fmt in internal.h Signed-off-by: Fabian Frederick Cc: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

FS/CACHEFILES: convert printk to pr_foo()

2014-06-06T23:08:14Z

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

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2014-04-12T21:49:50Z

Pull vfs updates from Al Viro: "The first vfs pile, with deep apologies for being very late in this window. Assorted cleanups and fixes, plus a large preparatory part of iov_iter work. There's a lot more of that, but it'll probably go into the next merge window - it *does* shape up nicely, removes a lot of boilerplate, gets rid of locking inconsistencie between aio_write and splice_write and I hope to get Kent's direct-io rewrite merged into the same queue, but some of the stuff after this point is having (mostly trivial) conflicts with the things already merged into mainline and with some I want more testing. This one passes LTP and xfstests without regressions, in addition to usual beating. BTW, readahead02 in ltp syscalls testsuite has started giving failures since "mm/readahead.c: fix readahead failure for memoryless NUMA nodes and limit readahead pages" - might be a false positive, might be a real regression..." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (63 commits) missing bits of "splice: fix racy pipe->buffers uses" cifs: fix the race in cifs_writev() ceph_sync_{,direct_}write: fix an oops on ceph_osdc_new_request() failure kill generic_file_buffered_write() ocfs2_file_aio_write(): switch to generic_perform_write() ceph_aio_write(): switch to generic_perform_write() xfs_file_buffered_aio_write(): switch to generic_perform_write() export generic_perform_write(), start getting rid of generic_file_buffer_write() generic_file_direct_write(): get rid of ppos argument btrfs_file_aio_write(): get rid of ppos kill the 5th argument of generic_file_buffered_write() kill the 4th argument of __generic_file_aio_write() lustre: don't open-code kernel_recvmsg() ocfs2: don't open-code kernel_recvmsg() drbd: don't open-code kernel_recvmsg() constify blk_rq_map_user_iov() and friends lustre: switch to kernel_sendmsg() ocfs2: don't open-code kernel_sendmsg() take iov_iter stuff to mm/iov_iter.c process_vm_access: tidy up a bit ...