linux-toradex.git/fs/cachefiles, branch tegra-10.9.7

CacheFiles: Update IMA counters when using dentry_open

2009-12-01T15:35:11+00:00

When IMA is active, using dentry_open without updating the
IMA counters will result in free/open imbalance errors when
fput is eventually called.

Signed-off-by: Marc Dionne 
Signed-off-by: David Howells 
Signed-off-by: Linus Torvalds

CacheFiles: Don't log lookup/create failing with ENOBUFS

2009-11-19T18:12:08+00:00

Don't log the CacheFiles lookup/create object routined failing with ENOBUFS as
under high memory load or high cache load they can do this quite a lot.  This
error simply means that the requested object cannot be created on disk due to
lack of space, or due to failure of the backing filesystem to find sufficient
resources.

Signed-off-by: David Howells

CacheFiles: Catch an overly long wait for an old active object

2009-11-19T18:12:05+00:00

Catch an overly long wait for an old, dying active object when we want to
replace it with a new one.  The probability is that all the slow-work threads
are hogged, and the delete can't get a look in.

What we do instead is:

 (1) if there's nothing in the slow work queue, we sleep until either the dying
     object has finished dying or there is something in the slow work queue
     behind which we can queue our object.

 (2) if there is something in the slow work queue, we return ETIMEDOUT to
     fscache_lookup_object(), which then puts us back on the slow work queue,
     presumably behind the deletion that we're blocked by.  We are then
     deferred for a while until we work our way back through the queue -
     without blocking a slow-work thread unnecessarily.

A backtrace similar to the following may appear in the log without this patch:

	INFO: task kslowd004:5711 blocked for more than 120 seconds.
	"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
	kslowd004     D 0000000000000000     0  5711      2 0x00000080
	 ffff88000340bb80 0000000000000046 ffff88002550d000 0000000000000000
	 ffff88002550d000 0000000000000007 ffff88000340bfd8 ffff88002550d2a8
	 000000000000ddf0 00000000000118c0 00000000000118c0 ffff88002550d2a8
	Call Trace:
	 [] ? trace_hardirqs_on+0xd/0xf
	 [] ? cachefiles_wait_bit+0x0/0xd [cachefiles]
	 [] cachefiles_wait_bit+0x9/0xd [cachefiles]
	 [] __wait_on_bit+0x43/0x76
	 [] ? ext3_xattr_get+0x1ec/0x270
	 [] out_of_line_wait_on_bit+0x69/0x74
	 [] ? cachefiles_wait_bit+0x0/0xd [cachefiles]
	 [] ? wake_bit_function+0x0/0x2e
	 [] cachefiles_mark_object_active+0x203/0x23b [cachefiles]
	 [] cachefiles_walk_to_object+0x558/0x827 [cachefiles]
	 [] cachefiles_lookup_object+0xac/0x12a [cachefiles]
	 [] fscache_lookup_object+0x1c7/0x214 [fscache]
	 [] fscache_object_state_machine+0xa5/0x52d [fscache]
	 [] fscache_object_slow_work_execute+0x5f/0xa0 [fscache]
	 [] slow_work_execute+0x18f/0x2d1
	 [] slow_work_thread+0x1c5/0x308
	 [] ? autoremove_wake_function+0x0/0x34
	 [] ? slow_work_thread+0x0/0x308
	 [] kthread+0x7a/0x82
	 [] child_rip+0xa/0x20
	 [] ? restore_args+0x0/0x30
	 [] ? kthread+0x0/0x82
	 [] ? child_rip+0x0/0x20
	1 lock held by kslowd004/5711:
	 #0:  (&sb->s_type->i_mutex_key#7/1){+.+.+.}, at: [] cachefiles_walk_to_object+0x1b3/0x827 [cachefiles]

Signed-off-by: David Howells

CacheFiles: Better showing of debugging information in active object problems

2009-11-19T18:12:02+00:00

Show more debugging information if cachefiles_mark_object_active() is asked to
activate an active object.

This may happen, for instance, if the netfs tries to register an object with
the same key multiple times.

The code is changed to (a) get the appropriate object lock to protect the
cookie pointer whilst we dereference it, and (b) get and display the cookie key
if available.

Signed-off-by: David Howells

CacheFiles: Mark parent directory locks as I_MUTEX_PARENT to keep lockdep happy

2009-11-19T18:11:58+00:00

Mark parent directory locks as I_MUTEX_PARENT in the callers of
cachefiles_bury_object() so that lockdep doesn't complain when that invokes
vfs_unlink():

=============================================
[ INFO: possible recursive locking detected ]
2.6.32-rc6-cachefs #47
---------------------------------------------
kslowd002/3089 is trying to acquire lock:
 (&sb->s_type->i_mutex_key#7){+.+.+.}, at: [] vfs_unlink+0x8b/0x128

but task is already holding lock:
 (&sb->s_type->i_mutex_key#7){+.+.+.}, at: [] cachefiles_walk_to_object+0x1b0/0x831 [cachefiles]

other info that might help us debug this:
1 lock held by kslowd002/3089:
 #0:  (&sb->s_type->i_mutex_key#7){+.+.+.}, at: [] cachefiles_walk_to_object+0x1b0/0x831 [cachefiles]

stack backtrace:
Pid: 3089, comm: kslowd002 Not tainted 2.6.32-rc6-cachefs #47
Call Trace:
 [] __lock_acquire+0x1649/0x16e3
 [] ? inode_has_perm+0x5f/0x61
 [] lock_acquire+0x57/0x6d
 [] ? vfs_unlink+0x8b/0x128
 [] mutex_lock_nested+0x54/0x292
 [] ? vfs_unlink+0x8b/0x128
 [] ? selinux_inode_permission+0x8e/0x90
 [] ? security_inode_permission+0x1c/0x1e
 [] ? inode_permission+0x99/0xa5
 [] vfs_unlink+0x8b/0x128
 [] ? kfree+0xed/0xf9
 [] cachefiles_bury_object+0xb6/0x420 [cachefiles]
 [] ? trace_hardirqs_on+0xd/0xf
 [] ? cachefiles_check_object_xattr+0x233/0x293 [cachefiles]
 [] cachefiles_walk_to_object+0x4ff/0x831 [cachefiles]
 [] ? finish_task_switch+0x0/0xb2
 [] cachefiles_lookup_object+0xac/0x12a [cachefiles]
 [] fscache_lookup_object+0x1c7/0x214 [fscache]
 [] fscache_object_state_machine+0xa5/0x52d [fscache]
 [] fscache_object_slow_work_execute+0x5f/0xa0 [fscache]
 [] slow_work_execute+0x18f/0x2d1
 [] slow_work_thread+0x1c5/0x308
 [] ? autoremove_wake_function+0x0/0x34
 [] ? slow_work_thread+0x0/0x308
 [] kthread+0x7a/0x82
 [] child_rip+0xa/0x20
 [] ? restore_args+0x0/0x30
 [] ? kthread+0x0/0x82
 [] ? child_rip+0x0/0x20

Signed-off-by: Daivd Howells

CacheFiles: Handle truncate unlocking the page we're reading

2009-11-19T18:11:55+00:00

Handle truncate unlocking the page we're attempting to read from the backing
device before the read has completed.

This was causing reports like the following to occur:

	Pid: 4765, comm: kslowd Not tainted 2.6.30.1 #1
	Call Trace:
	 [] ? cachefiles_read_waiter+0xd9/0x147 [cachefiles]
	 [] ? __wait_on_bit+0x60/0x6f
	 [] ? __wake_up_common+0x3f/0x71
	 [] ? __wake_up+0x30/0x44
	 [] ? __wake_up_bit+0x28/0x2d
	 [] ? ext3_truncate+0x4d7/0x8ed [ext3]
	 [] ? pagevec_lookup+0x17/0x1f
	 [] ? unmap_mapping_range+0x59/0x1ff
	 [] ? __wake_up+0x30/0x44
	 [] ? vmtruncate+0xc2/0xe2
	 [] ? inode_setattr+0x22/0x10a
	 [] ? ext3_setattr+0x17b/0x1e6 [ext3]
	 [] ? notify_change+0x186/0x2c9
	 [] ? cachefiles_attr_changed+0x133/0x1cd [cachefiles]
	 [] ? cachefiles_lookup_object+0xcf/0x12a [cachefiles]
	 [] ? fscache_lookup_object+0x110/0x122 [fscache]
	 [] ? fscache_object_slow_work_execute+0x590/0x6bc
	[fscache]
	 [] ? slow_work_thread+0x285/0x43a
	 [] ? autoremove_wake_function+0x0/0x2e
	 [] ? slow_work_thread+0x0/0x43a
	 [] ? kthread+0x54/0x81
	 [] ? child_rip+0xa/0x20
	 [] ? kthread+0x0/0x81
	 [] ? child_rip+0x0/0x20
	CacheFiles: I/O Error: Readpage failed on backing file 200000000000810
	FS-Cache: Cache cachefiles stopped due to I/O error

Reported-by: Christian Kujau 
Reported-by: Takashi Iwai 
Reported-by: Duc Le Minh 
Signed-off-by: David Howells

CacheFiles: Don't write a full page if there's only a partial page to cache

2009-11-19T18:11:52+00:00

cachefiles_write_page() writes a full page to the backing file for the last
page of the netfs file, even if the netfs file's last page is only a partial
page.

This causes the EOF on the backing file to be extended beyond the EOF of the
netfs, and thus the backing file will be truncated by cachefiles_attr_changed()
called from cachefiles_lookup_object().

So we need to limit the write we make to the backing file on that last page
such that it doesn't push the EOF too far.

Also, if a backing file that has a partial page at the end is expanded, we
discard the partial page and refetch it on the basis that we then have a hole
in the file with invalid data, and should the power go out...  A better way to
deal with this could be to record a note that the partial page contains invalid
data until the correct data is written into it.

This isn't a problem for netfs's that discard the whole backing file if the
file size changes (such as NFS).

Signed-off-by: David Howells

FS-Cache: Allow the current state of all objects to be dumped

2009-11-19T18:11:04+00:00

Allow the current state of all fscache objects to be dumped by doing:

	cat /proc/fs/fscache/objects

By default, all objects and all fields will be shown.  This can be restricted
by adding a suitable key to one of the caller's keyrings (such as the session
keyring):

	keyctl add user fscache:objlist "" @s

The  are:

	K	Show hexdump of object key (don't show if not given)
	A	Show hexdump of object aux data (don't show if not given)

And paired restrictions:

	C	Show objects that have a cookie
	c	Show objects that don't have a cookie
	B	Show objects that are busy
	b	Show objects that aren't busy
	W	Show objects that have pending writes
	w	Show objects that don't have pending writes
	R	Show objects that have outstanding reads
	r	Show objects that don't have outstanding reads
	S	Show objects that have slow work queued
	s	Show objects that don't have slow work queued

If neither side of a restriction pair is given, then both are implied.  For
example:

	keyctl add user fscache:objlist KB @s

shows objects that are busy, and lists their object keys, but does not dump
their auxiliary data.  It also implies "CcWwRrSs", but as 'B' is given, 'b' is
not implied.

Signed-off-by: David Howells

enforce ->sync_fs is only called for rw superblock

2009-06-12T01:36:06+00:00

Make sure a superblock really is writeable by checking MS_RDONLY
under s_umount.  sync_filesystems needed some re-arragement for
that, but all but one sync_filesystem caller had the correct locking
already so that we could add that check there.  cachefiles grew
s_umount locking.

I've also added a WARN_ON to sync_filesystem to assert this for
future callers.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

vfs: Rename fsync_super() to sync_filesystem() (version 4)

2009-06-12T01:36:04+00:00

Rename the function so that it better describe what it really does. Also
remove the unnecessary include of buffer_head.h.

Signed-off-by: Jan Kara 
Signed-off-by: Al Viro