summaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2010-09-22 13:04:54 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2010-09-22 17:22:38 -0700
commitc227e69028473c7c7994a9b0a2cc0034f3f7e0fe (patch)
treee11e51f5eec4c2c82a8ef7839de74407f470176c /fs
parenta9e31765e7d528858e1b0c202b823cf4df7577ca (diff)
downloadlinux-c227e69028473c7c7994a9b0a2cc0034f3f7e0fe.tar.gz
linux-c227e69028473c7c7994a9b0a2cc0034f3f7e0fe.tar.bz2
linux-c227e69028473c7c7994a9b0a2cc0034f3f7e0fe.zip
/proc/vmcore: fix seeking
Commit 73296bc611 ("procfs: Use generic_file_llseek in /proc/vmcore") broke seeking on /proc/vmcore. This changes it back to use default_llseek in order to restore the original behaviour. The problem with generic_file_llseek is that it only allows seeks up to inode->i_sb->s_maxbytes, which is zero on procfs and some other virtual file systems. We should merge generic_file_llseek and default_llseek some day and clean this up in a proper way, but for 2.6.35/36, reverting vmcore is the safer solution. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Frederic Weisbecker <fweisbec@gmail.com> Reported-by: CAI Qian <caiqian@redhat.com> Tested-by: CAI Qian <caiqian@redhat.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs')
-rw-r--r--fs/proc/vmcore.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 91c817ff02c3..2367fb3f70bc 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -163,7 +163,7 @@ static ssize_t read_vmcore(struct file *file, char __user *buffer,
static const struct file_operations proc_vmcore_operations = {
.read = read_vmcore,
- .llseek = generic_file_llseek,
+ .llseek = default_llseek,
};
static struct vmcore* __init get_new_element(void)