From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH v2] vmcore: copy fractional pages into buffers in the kdump 2nd kernel
Date: Fri, 31 Jan 2014 18:57:53 +0900 [thread overview]
Message-ID: <52EB73A1.3080409@jp.fujitsu.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE971E47E1@BPXM01GP.gisp.nec.co.jp>
(2014/01/31 11:36), Atsushi Kumagai wrote:
> Hello HATAYAMA-san,
>
> On 2013/12/09 17:06:18, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
>> This is a patch for fixing mmap failure due to fractional page issue.
>>
>> This patch might be still a bit too large as a single patch and might need to split.
>> If you think patch refactoring is needed, please suggest.
>>
>> Change Log:
>>
>> v1 => v2)
>>
>> - Copy fractional pages from 1st kernel to 2nd kernel to reduce read
>> to the fractional pages for reliability.
>>
>> - Deal with the case where multiple System RAM areas are contained in
>> a single fractional page.
>>
>> Test:
>>
>> Tested on X86_64. Fractional pages are created using memmap= kernel
>> parameter on the kdump 1st kernel.
>
> Could you tell me more details about how to reproduce this ?
> I tried to create such fractional pages to test the patch at
> the end of this mail, by using memmap= kernel parameter as you said
> like below:
>
> # cat /proc/iomem
> ...
> 100000000-10fff57ff : System RAM
> 10fff5800-1100057ff : reserved
> 110005800-11fffffff : System RAM
>
> However, I couldn't face the mmap() failure and makedumpfile worked
> normally even using mmap() on linux-3.12.1. What am I missing here ?
>
This patch set tries to reduce potential risk on accessing i.e. creating
page tables reading memory outside System RAM regions. The potential risk
I intend here is for example effect of accessing mmio region.
If you didn't see any failure except for mmap() failure on fractional pages,
there's no potential risk on your system in the sense of what I mean above.
Or you could probably see different behavior by choosing other System RAM
region that resides in the memory that is used for something special.
Also, in early phase, our design didn't care about this kind of fractional pages
because we don't think there were many such systems on real world. But the
bug report came earlier than we expected. So, I think we should design
carefully here around at least as long as they can be done relatively simply.
# Sorry for delaying my work...
Of course, I think both kernel and makedumpfile address the issue together
to reduce potential risk as much as possible.
--
Thanks.
HATAYAMA, Daisuke
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2014-01-31 9:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 8:06 [PATCH v2] vmcore: copy fractional pages into buffers in the kdump 2nd kernel HATAYAMA Daisuke
2013-12-09 8:06 ` HATAYAMA Daisuke
2013-12-11 11:33 ` WANG Chao
2013-12-11 11:33 ` WANG Chao
2013-12-12 16:42 ` Vivek Goyal
2013-12-12 16:42 ` Vivek Goyal
2013-12-13 1:42 ` HATAYAMA Daisuke
2013-12-13 1:42 ` HATAYAMA Daisuke
2014-01-31 2:36 ` Atsushi Kumagai
2014-01-31 9:57 ` HATAYAMA Daisuke [this message]
2014-02-06 9:38 ` Atsushi Kumagai
2014-02-14 12:18 ` HATAYAMA Daisuke
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=52EB73A1.3080409@jp.fujitsu.com \
--to=d.hatayama@jp.fujitsu.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
/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.