linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>,
	"bhe@redhat.com" <bhe@redhat.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"dyoung@redhat.com" <dyoung@redhat.com>,
	"chaowang@redhat.com" <chaowang@redhat.com>
Subject: Re: /proc/vmcore mmap() failure issue
Date: Mon, 25 Nov 2013 09:41:50 -0500	[thread overview]
Message-ID: <20131125144150.GC21378@redhat.com> (raw)
In-Reply-To: <529311F1.90603@jp.fujitsu.com>

On Mon, Nov 25, 2013 at 06:01:37PM +0900, HATAYAMA Daisuke wrote:

[..]
> > I agree to avoid this issue by fixing makedumpfile as workaround while to
> > fix kernel is so tough and risky. However, it sounds strange to me to fix
> > userspace side elaborately for such definite kernel issue whose cause is
> > known, so we should fix the kernel itself.
> > 
> 
> > Otherwise, will you continue to add specific fixes into user tools to
> > address kernel issues like this case ?
> > 
> 
> makedumpfile supports a wide range of kernel versions and needs to satisfy
> backward compatibility. mmap() on /proc/vmcore might be backported to some of
> the old versions on some distributions if necessary. Then, it's hard to fix
> each old kernel at each back port. The method that can be applied to all the
> kernels in general, is necessary.
> 
> Also, looking at ia64 case where there's boot loader data on partial pages,
> there could be other environments where partial pages contain other important
> data other components have. So, the issue depends not only on kernels but also
> other components such as boot loader and firmwares that can put data on
> partial pages. We need to get there as long as there's important data there
> and we have access to there.

Hi Atsushi, Hatayama,

So even if we fix the mmap() issue in kernel, looks like it will be a
good idea to ship the fix in makedumpfile as there have been a kernel
release where mmap() will cause issues.

Having said that, I think we need to fix it in kernel also. I was not sure
that what's the right fix. Should we truncate partial pages or should
we just copy partial pages from old memory to new kernel's memory and fill
partial page with zeros. And that's why I was hoping that makedumpfile
can fill the gap.

Copying partial pages to new memory seems like a safer approach. So may
be we can take a fix in makeudmpfile and another in kernel.

Hatayama, I know that in the past your initial mmap() patches were copying
partial pages to new kernel's memory. Would you like to resurrect that
patch again?

Thanks
Vivek

  reply	other threads:[~2013-11-25 14:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-13 20:41 /proc/vmcore mmap() failure issue Vivek Goyal
2013-11-13 21:04 ` Vivek Goyal
2013-11-13 21:14   ` H. Peter Anvin
2013-11-13 22:41     ` Vivek Goyal
2013-11-13 22:44       ` H. Peter Anvin
2013-11-13 23:00         ` Vivek Goyal
2013-11-13 23:08           ` H. Peter Anvin
2013-11-14 10:31 ` HATAYAMA Daisuke
2013-11-14 15:13   ` Vivek Goyal
2013-11-15  9:41     ` HATAYAMA Daisuke
2013-11-15 14:26       ` Vivek Goyal
2013-11-18  0:51         ` Atsushi Kumagai
2013-11-18 13:55           ` Vivek Goyal
2013-11-20  5:29             ` Atsushi Kumagai
2013-11-20 14:59               ` Vivek Goyal
2013-11-21  5:00                 ` Atsushi Kumagai
2013-11-21  8:31                   ` HATAYAMA Daisuke
2013-11-21 16:52                     ` Vivek Goyal
2013-11-25  8:10                       ` Atsushi Kumagai
2013-11-25  9:01                         ` HATAYAMA Daisuke
2013-11-25 14:41                           ` Vivek Goyal [this message]
2013-11-26  1:51                             ` Atsushi Kumagai
2013-11-26  5:16                             ` HATAYAMA Daisuke
2013-11-19  9:55           ` HATAYAMA Daisuke
2013-11-20  5:27             ` Atsushi Kumagai
2013-11-20  6:43               ` HATAYAMA Daisuke
2013-11-26  1:52                 ` Atsushi Kumagai
2013-11-21  7:14               ` chaowang
2013-11-25  8:09                 ` Atsushi Kumagai
2013-11-26  3:29                   ` chaowang

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=20131125144150.GC21378@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=bhe@redhat.com \
    --cc=chaowang@redhat.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=kumagai-atsushi@mxc.nes.nec.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).