All of lore.kernel.org
 help / color / mirror / Atom feed
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: Jingbai Ma <jingbai.ma@hp.com>
Cc: bhe@redhat.com, nishimura@mxp.nes.nec.co.jp,
	usui@mxm.nes.nec.co.jp, lisa.mitchell@hp.com, ruyang@redhat.com,
	tachibana@mxm.nes.nec.co.jp, anderson@redhat.com,
	chaowang@redhat.com, kumagai-atsushi@mxc.nes.nec.co.jp,
	kexec@lists.infradead.org, vgoyal@redhat.com,
	crash-utility@redhat.com
Subject: Re: [PATCH] makedumpfile: fix max_mapnr issue on system has over 44-bit addressing
Date: Tue, 08 Oct 2013 14:41:39 +0900	[thread overview]
Message-ID: <52539B13.6060406@jp.fujitsu.com> (raw)
In-Reply-To: <52429BF1.3050303@hp.com>

(2013/09/25 17:16), Jingbai Ma wrote:
> On 09/25/2013 08:35 AM, HATAYAMA Daisuke wrote:
>> (2013/09/24 21:49), Jingbai Ma wrote:
>>> This patch will fix a bug of makedumpfile doesn't work correctly on
>>> system
>>> has over 44-bit addressing in compression dump mode.
>>> This bug was posted here:
>>> http://lists.infradead.org/pipermail/kexec/2013-September/009587.html
>>>
>>> This patch will add a new field in struct kdump_sub_header.
>>> unsigned long max_mapnr;
>>>
>>> And the old "unsigned int max_mapnr" in struct disk_dump_header will
>>> not be used anymore. But still be there for compatibility purpose.
>>>
>>> This patch will change the header_version to 6.
>>>
>>> The corresponding patch for crash utility will be sent out separately.
>>>
>>> This patch doesn't change sadump_header.
>>> Because of in sadump file, there is no any sub-header, it has to change
>>> the sadump_header itself.
>>> And if do so, will cause backwards-compatibility issue.
>>> So it could be a separate patch if needed.
>>>
>>> Signed-off-by: Jingbai Ma <jingbai.ma@hp.com>
>>> ---
>>> IMPLEMENTATION | 1 +
>>> diskdump_mod.h | 5 ++++-
>>> makedumpfile.c | 28 ++++++++++++++++++++++------
>>> 3 files changed, 27 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/IMPLEMENTATION b/IMPLEMENTATION
>>> index f0f3135..d576811 100644
>>> --- a/IMPLEMENTATION
>>> +++ b/IMPLEMENTATION
>>> @@ -77,6 +77,7 @@
>>> unsigned long size_note; /* header_version 4 and later */
>>> off_t offset_eraseinfo; /* header_version 5 and later */
>>> unsigned long size_eraseinfo; /* header_version 5 and later */
>>> + unsigned long max_mapnr; /* header_version 6 and later */
>>
>> x86 PAE mode can represents 52-bit physical addresses and so 40-bit
>> physical
>> page frames. On x86_32 unsigned long has 32-bit length only. So, you should
>> define max_mapnr as unsigned long long.
>>
>
> Good catch, I forgot x86 PAE mode also may exceed 32-bit length.
> Will fix it.
>

Though perhaps you've already noticed, both start_pfn and end_pfn in kdump sub
header have 32-bit length on x86_32. These need to be extended to 64-bit length,
too.

/*
  * Sub header for KDUMP
  * But Common header of KDUMP is disk_dump_header of diskdump.
  */
struct kdump_sub_header {
         unsigned long   phys_base;
         int             dump_level;     /* header_version 1 and later */
         int             split;          /* header_version 2 and later */
         unsigned long   start_pfn;      /* header_version 2 and later */
         unsigned long   end_pfn;        /* header_version 2 and later */
         off_t           offset_vmcoreinfo;/* header_version 3 and later */
         unsigned long   size_vmcoreinfo;  /* header_version 3 and later */
         off_t           offset_note;      /* header_version 4 and later */
         unsigned long   size_note;        /* header_version 4 and later */
         off_t           offset_eraseinfo; /* header_version 5 and later */
         unsigned long   size_eraseinfo;   /* header_version 5 and later */
};

-- 
Thanks.
HATAYAMA, Daisuke


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2013-10-08  5:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-24 12:49 [PATCH] makedumpfile: fix max_mapnr issue on system has over 44-bit addressing Jingbai Ma
2013-09-25  0:35 ` HATAYAMA Daisuke
2013-09-25  8:16   ` Jingbai Ma
2013-09-25  8:39     ` HATAYAMA Daisuke
2013-09-25  8:54       ` Jingbai Ma
2013-10-02  6:20         ` Atsushi Kumagai
2013-10-03 14:37           ` Ma, Jingbai (Kingboard)
2013-10-08  5:41     ` HATAYAMA Daisuke [this message]
2013-10-08  7:26       ` Jingbai Ma
2013-10-08  8:34         ` HATAYAMA Daisuke
2013-10-08  9:32           ` Jingbai Ma

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=52539B13.6060406@jp.fujitsu.com \
    --to=d.hatayama@jp.fujitsu.com \
    --cc=anderson@redhat.com \
    --cc=bhe@redhat.com \
    --cc=chaowang@redhat.com \
    --cc=crash-utility@redhat.com \
    --cc=jingbai.ma@hp.com \
    --cc=kexec@lists.infradead.org \
    --cc=kumagai-atsushi@mxc.nes.nec.co.jp \
    --cc=lisa.mitchell@hp.com \
    --cc=nishimura@mxp.nes.nec.co.jp \
    --cc=ruyang@redhat.com \
    --cc=tachibana@mxm.nes.nec.co.jp \
    --cc=usui@mxm.nes.nec.co.jp \
    --cc=vgoyal@redhat.com \
    /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.