linux-stable.git/fs/cachefiles, branch v3.18.136

fscache, cachefiles: remove redundant variable 'cache'

2018-12-17T09:07:11+00:00

[ Upstream commit 31ffa563833576bd49a8bf53120568312755e6e2 ]

Variable 'cache' is being assigned but is never used hence it is
redundant and can be removed.

Cleans up clang warning:
warning: variable 'cache' set but not used [-Wunused-but-set-variable]

Signed-off-by: Colin Ian King 
Signed-off-by: David Howells 
Signed-off-by: Sasha Levin

cachefiles: fix the race between cachefiles_bury_object() and rmdir(2)

2018-11-10T15:39:23+00:00

commit 169b803397499be85bdd1e3d07d6f5e3d4bd669e upstream.

the victim might've been rmdir'ed just before the lock_rename();
unlike the normal callers, we do not look the source up after the
parents are locked - we know it beforehand and just recheck that it's
still the child of what used to be its parent.  Unfortunately,
the check is too weak - we don't spot a dead directory since its
->d_parent is unchanged, dentry is positive, etc.  So we sail all
the way to ->rename(), with hosting filesystems _not_ expecting
to be asked renaming an rmdir'ed subdirectory.

The fix is easy, fortunately - the lock on parent is sufficient for
making IS_DEADDIR() on child safe.

Cc: stable@vger.kernel.org
Fixes: 9ae326a69004 (CacheFiles: A cache that backs onto a mounted filesystem)
Signed-off-by: Al Viro 
Signed-off-by: David Howells 
Signed-off-by: Greg Kroah-Hartman

cachefiles: Wait rather than BUG'ing on "Unexpected object collision"

2018-09-05T07:16:21+00:00

[ Upstream commit c2412ac45a8f8f1cd582723c1a139608694d410d ]

If we meet a conflicting object that is marked FSCACHE_OBJECT_IS_LIVE in
the active object tree, we have been emitting a BUG after logging
information about it and the new object.

Instead, we should wait for the CACHEFILES_OBJECT_ACTIVE flag to be cleared
on the old object (or return an error).  The ACTIVE flag should be cleared
after it has been removed from the active object tree.  A timeout of 60s is
used in the wait, so we shouldn't be able to get stuck there.

Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem")
Signed-off-by: Kiran Kumar Modukuri 
Signed-off-by: David Howells 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cachefiles: Fix refcounting bug in backing-file read monitoring

2018-09-05T07:16:21+00:00

[ Upstream commit 934140ab028713a61de8bca58c05332416d037d1 ]

cachefiles_read_waiter() has the right to access a 'monitor' object by
virtue of being called under the waitqueue lock for one of the pages in its
purview.  However, it has no ref on that monitor object or on the
associated operation.

What it is allowed to do is to move the monitor object to the operation's
to_do list, but once it drops the work_lock, it's actually no longer
permitted to access that object.  However, it is trying to enqueue the
retrieval operation for processing - but it can only do this via a pointer
in the monitor object, something it shouldn't be doing.

If it doesn't enqueue the operation, the operation may not get processed.
If the order is flipped so that the enqueue is first, then it's possible
for the work processor to look at the to_do list before the monitor is
enqueued upon it.

Fix this by getting a ref on the operation so that we can trust that it
will still be there once we've added the monitor to the to_do list and
dropped the work_lock.  The op can then be enqueued after the lock is
dropped.

The bug can manifest in one of a couple of ways.  The first manifestation
looks like:

 FS-Cache:
 FS-Cache: Assertion failed
 FS-Cache: 6 == 5 is false
 ------------[ cut here ]------------
 kernel BUG at fs/fscache/operation.c:494!
 RIP: 0010:fscache_put_operation+0x1e3/0x1f0
 ...
 fscache_op_work_func+0x26/0x50
 process_one_work+0x131/0x290
 worker_thread+0x45/0x360
 kthread+0xf8/0x130
 ? create_worker+0x190/0x190
 ? kthread_cancel_work_sync+0x10/0x10
 ret_from_fork+0x1f/0x30

This is due to the operation being in the DEAD state (6) rather than
INITIALISED, COMPLETE or CANCELLED (5) because it's already passed through
fscache_put_operation().

The bug can also manifest like the following:

 kernel BUG at fs/fscache/operation.c:69!
 ...
    [exception RIP: fscache_enqueue_operation+246]
 ...
 #7 [ffff883fff083c10] fscache_enqueue_operation at ffffffffa0b793c6
 #8 [ffff883fff083c28] cachefiles_read_waiter at ffffffffa0b15a48
 #9 [ffff883fff083c48] __wake_up_common at ffffffff810af028

I'm not entirely certain as to which is line 69 in Lei's kernel, so I'm not
entirely clear which assertion failed.

Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem")
Reported-by: Lei Xue 
Reported-by: Vegard Nossum 
Reported-by: Anthony DeRobertis 
Reported-by: NeilBrown 
Reported-by: Daniel Axtens 
Reported-by: Kiran Kumar Modukuri 
Signed-off-by: David Howells 
Reviewed-by: Daniel Axtens 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

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

2014-10-14T06:40:15+00:00

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:21+00:00

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:05+00:00

Signed-off-by: Al Viro

CacheFiles: Handle object being killed before being set up

2014-09-30T13:50:28+00:00

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:35+00:00

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:53+00:00

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