- 20 Dec, 2012 40 commits
-
-
Jeff Layton authored
Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Clearly, we can't handle the NULL filename case, but we can deal with the case where there's a real pathname. Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
...as always, rename is the messiest of the bunch. We have to track whether to retry or not via a separate flag since the error handling is already quite complex. Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
...so we can pass in LOOKUP_REVAL. For now, nothing does yet. Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Where we can pass in LOOKUP_DIRECTORY or LOOKUP_REVAL. Any other flags passed in here are currently ignored. Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
This function is expected to be called from path-based syscalls to help them decide whether to try the lookup and call again in the event that they got an -ESTALE return back on an earier try. Currently, we only retry the call once on an ESTALE error, but in the event that we decide that that's not enough in the future, we should be able to change the logic in this helper without too much effort. Signed-off-by:
-
Al Viro authored
Merge branch 'fscache' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into for-linus
-
NeilBrown authored
NFS appears to use d_obtain_alias() to create the root dentry rather than d_make_root. This can cause 'prepend_path()' to complain that the root has a weird name if an NFS filesystem is lazily unmounted. e.g. if "/mnt" is an NFS mount then { cd /mnt; umount -l /mnt ; ls -l /proc/self/cwd; } will cause a WARN message like WARNING: at /home/git/linux/fs/dcache.c:2624 prepend_path+0x1d7/0x1e0() ... Root dentry has weird name <> to appear in kernel logs. So change d_obtain_alias() to use "/" rather than "" as the anonymous name. Signed-off-by:NeilBrown <neilb@suse.de> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Alessio Igor Bogani authored
Commit 8e22cc88 removes the (un)lock_super function definitions but forgets to remove their prototypes. Signed-off-by:
Alessio Igor Bogani <abogani@kernel.org> Signed-off-by:
-
Marco Stornelli authored
Removed vmtruncate Signed-off-by:
Marco Stornelli <marco.stornelli@gmail.com> Signed-off-by:
-
Marco Stornelli authored
Removed vmtruncate Signed-off-by:
-
Marco Stornelli authored
Removed vmtruncate Signed-off-by:
-
Marco Stornelli authored
Removed vmtruncate Signed-off-by:
Anton Altaparmakov <anton@tuxera.com> Signed-off-by:
-
Marco Stornelli authored
Removed vmtruncate Signed-off-by:
-
Marco Stornelli authored
Removed vmtruncate Signed-off-by:
-
Marco Stornelli authored
Removed vmtruncate Signed-off-by:
-
Marco Stornelli authored
Removed vmtruncate Signed-off-by:
-
Marco Stornelli authored
Removed vmtruncate Signed-off-by:
-
Marco Stornelli authored
Removed vmtruncate Signed-off-by:
-
Marco Stornelli authored
Removed vmtruncate Signed-off-by:
-
David Howells authored
Provide fscache_cancel_op() with a pointer to a function it should invoke under lock if it cancels an operation. Use this to clear the remaining page count upon cancellation of a pending retrieval operation so that fscache_release_retrieval_op() doesn't get an assertion failure (see below). This can happen when a signal occurs, say from CTRL-C being pressed during data retrieval. FS-Cache: Assertion failed 3 == 0 is false ------------[ cut here ]------------ kernel BUG at fs/fscache/page.c:237! invalid opcode: 0000 [#641] SMP Modules linked in: cachefiles(F) nfsv4(F) nfsv3(F) nfsv2(F) nfs(F) fscache(F) auth_rpcgss(F) nfs_acl(F) lockd(F) sunrpc(F) CPU 0 Pid: 6075, comm: slurp-q Tainted: GF D 3.7.0-rc8-fsdevel+ #411 /DG965RY RIP: 0010:[<ffffffffa007f328>] [<ffffffffa007f328>] fscache_release_retrieval_op+0x75/0xff [fscache] RSP: 0000:ffff88001c6d7988 EFLAGS: 00010296 RAX: 000000000000000f RBX: ffff880014cdfe00 RCX: ffffffff6c102000 RDX: ffffffff8102d1ad RSI: ffffffff6c102000 RDI: ffffffff8102d1d6 RBP: ffff88001c6d7998 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffe00 R13: ffff88001c6d7ab4 R14: ffff88001a8638a0 R15: ffff88001552b190 FS: 00007f877aaf0700(0000) GS:ffff88003bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007fff11378fd2 CR3: 000000001c6c6000 CR4: 00000000000007f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process slurp-q (pid: 6075, threadinfo ffff88001c6d6000, task ffff88001c6c4080) Stack: ffffffffa007ec07 ffff880014cdfe00 ffff88001c6d79c8 ffffffffa007db4d ffffffffa007ec07 ffff880014cdfe00 00000000fffffe00 ffff88001c6d7ab4 ffff88001c6d7a38 ffffffffa008116d 0000000000000000 ffff88001c6c4080 Call Trace: [<ffffffffa007ec07>] ? fscache_cancel_op+0x194/0x1cf [fscache] [<ffffffffa007db4d>] fscache_put_operation+0x135/0x2ed [fscache] [<ffffffffa007ec07>] ? fscache_cancel_op+0x194/0x1cf [fscache] [<ffffffffa008116d>] __fscache_read_or_alloc_pages+0x413/0x4bc [fscache] [<ffffffff810ac8ae>] ? __alloc_pages_nodemask+0x195/0x75c [<ffffffffa00aab0f>] __nfs_readpages_from_fscache+0x86/0x13d [nfs] [<ffffffffa00a5fe0>] nfs_readpages+0x186/0x1bd [nfs] [<ffffffff810d23c8>] ? alloc_pages_current+0xc7/0xe4 [<ffffffff810a68b5>] ? __page_cache_alloc+0x84/0x91 [<ffffffff810af912>] ? __do_page_cache_readahead+0xa6/0x2e0 [<ffffffff810afaa3>] __do_page_cache_readahead+0x237/0x2e0 [<ffffffff810af912>] ? __do_page_cache_readahead+0xa6/0x2e0 [<ffffffff810afe3e>] ra_submit+0x1c/0x20 [<ffffffff810b019b>] ondemand_readahead+0x359/0x382 [<ffffffff810b0279>] page_cache_sync_readahead+0x38/0x3a [<ffffffff810a77b5>] generic_file_aio_read+0x26b/0x637 [<ffffffffa00f1852>] ? nfs_mark_delegation_referenced+0xb/0xb [nfsv4] [<ffffffffa009cc85>] nfs_file_read+0xaa/0xcf [nfs] [<ffffffff810db5b3>] do_sync_read+0x91/0xd1 [<ffffffff810dbb8b>] vfs_read+0x9b/0x144 [<ffffffff810dbc78>] sys_read+0x44/0x75 [<ffffffff81422892>] system_call_fastpath+0x16/0x1b Signed-off-by:David Howells <dhowells@redhat.com>
-
