From: Arnd Bergmann <arnd@arndb.de>
To: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Cc: CAI Qian <caiqian@redhat.com>,
fweisbec@gmail.com, mingo@elte.hu,
kexec <kexec@lists.infradead.org>,
viro@zeniv.linux.org.uk, jkacur@redhat.com,
akpm@linux-foundation.org, tglx@linutronix.de,
kamezawa hiroyu <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: fix /proc/vmcore seek
Date: Fri, 3 Sep 2010 13:45:50 +0200 [thread overview]
Message-ID: <201009031345.50837.arnd@arndb.de> (raw)
In-Reply-To: <20100903100050.1943c4c3.oomichi@mxs.nes.nec.co.jp>
On Friday 03 September 2010, Ken'ichi Ohmichi wrote:
> Thank you for investigating.
> IIUC, this problem may happen if using "cp" command instead of
> makedumpfile.
>
> Does the following method in generic_file_llseek_unlocked() fail ?
> Is inode->i_sb->s_maxbytes too small ?
>
> 65 if (offset < 0 || offset > inode->i_sb->s_maxbytes)
> 66 return -EINVAL;
>
Yes, that is the main difference between generic_file_llseek and
default_llseek, besides the use of the BKL. We have discussed
changing this before, but so far without a conclusive answer.
If we can come up with a better test here, we might be able
to just kill default_llseek in favor of generic_file_llseek.
The problem is handling the special cases here. For a /proc file,
s_maxbytes is probably always zero, but that could be changed,
same for file systems using get_sb_single.
For some reason, get_sb_pseudo sets does set s_maxbytes while
get_sb_single/simple_fill_super does not.
Character devices are also special, because the s_maxbytes for
them AFAICT is the one from the file system holding the device,
so using generic_file_llseek would definitely be incorrect for them.
Arnd
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2010-09-03 11:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <839326586.1621551283237394919.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2010-08-31 6:50 ` makedumpfile failed for 2.6.36-rc2 caiqian
2010-08-31 7:28 ` Ken'ichi Ohmichi
2010-08-31 8:29 ` CAI Qian
2010-09-01 4:33 ` Ken'ichi Ohmichi
2010-09-01 5:16 ` CAI Qian
2010-09-02 11:51 ` CAI Qian
2010-09-02 12:20 ` fix /proc/vmcore seek Arnd Bergmann
2010-09-02 14:23 ` CAI Qian
2010-09-03 1:00 ` Ken'ichi Ohmichi
2010-09-03 11:45 ` Arnd Bergmann [this message]
2010-09-03 20:58 ` Andrew Morton
2010-09-03 21:10 ` Frederic Weisbecker
2010-09-06 1:10 ` [PATCH][mmotm] unsigned offset llseek support (Was " KAMEZAWA Hiroyuki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201009031345.50837.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=akpm@linux-foundation.org \
--cc=caiqian@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jkacur@redhat.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kexec@lists.infradead.org \
--cc=mingo@elte.hu \
--cc=oomichi@mxs.nes.nec.co.jp \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.