fix /proc/vmcore seek

Ken'ichi Ohmichi oomichi at mxs.nes.nec.co.jp
Thu Sep 2 21:00:50 EDT 2010


Hi CAI, Arnd,

On Thu, 2 Sep 2010 10:23:56 -0400 (EDT)
CAI Qian <caiqian at redhat.com> wrote:
> 
> ----- "Arnd Bergmann" <arnd at arndb.de> wrote:
> 
> > 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.
> > 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Cc: Frederic Weisbecker <fweisbec at gmail.com>
> > Cc: stable at kernel.org
> > 
> > ---
> > On Thursday 02 September 2010, CAI Qian wrote:
> > > 
> > > Ken'ichi, it turned out this kernel patch caused makedumpfile
> > failure below.
> > > I am not sure if this is a kernel bug or makedumpfile needs to catch
> > up with
> > > the change.
> > 
> > It doesn't matter who is correct here. A user program regressed
> > because of a
> > kernel change, so we need to fix the kernel. Thanks for the report!
> > 
> > Please try this patch.
>
> Confirmed makedumpfile is working again after applied this patch.

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;


Thanks
Ken'ichi Ohmichi

> > --- 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)
> > 



More information about the kexec mailing list