All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: "Zhang, Jun" <jun.zhang@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "x86@kernel.org" <x86@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Fleming, Matt" <matt.fleming@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).
Date: Fri, 2 Nov 2012 11:08:59 -0400	[thread overview]
Message-ID: <20121102150859.GG25658@windriver.com> (raw)
In-Reply-To: <88DC34334CA3444C85D647DBFA962C270FD7F039@SHSMSX102.ccr.corp.intel.com>

[RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).] On 01/11/2012 (Thu 08:49) Zhang, Jun wrote:

> Hello, Anvin
> 
> Thank for your advice.
> 
> Hello, All
> 
> the next patch is made by 2), please review it. Thanks!
> 
> Subject: [PATCH] When we are doing a crash dump, we still need non-E820_RAM
>  memory information in order to do I/O. So only remove all
>  RAM ranges which need to be dumped.

It is typical to do a "short log" in the subject, and then a "long log"
in what would be the following paragraph, i.e.

 ---------
 Subject: crash dump: don't delete non-E820_RAM during init

 Currently we delete the non-E820_RAM, which causes <describe the end
 user symptoms here -- i.e. how things visibly break>

 This happens because <describe the underlying technical reason
 that causes the problem>

 We can fix this by doing <describe the non-obvious aspects of your
 change and why it is the right way to fix the problem>
 ---------

This "rule of three" is a good way to write commit logs. Just remember
(1)symptoms, (2)underlying problem, (3)how best to fix it.

Also, ...

> 
> Signed-off-by: jzha144 <jun.zhang@intel.com>
> ---
>  arch/x86/kernel/e820.c  |    8 --------
>  arch/x86/kernel/setup.c |   22 ++++++++++++++++++++++
>  2 files changed, 22 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index df06ade..0bc1687 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -844,14 +844,6 @@ static int __init parse_memmap_opt(char *p)
>  		return -EINVAL;
>  
>  	if (!strncmp(p, "exactmap", 8)) {
> -#ifdef CONFIG_CRASH_DUMP
> -		/*
> -		 * If we are doing a crash dump, we still need to know
> -		 * the real mem size before original memory map is
> -		 * reset.
> -		 */
> -		saved_max_pfn = e820_end_of_ram_pfn();
> -#endif
>  		e820.nr_map = 0;
>  		userdef = 1;
>  		return 0;
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index ca45696..5eb178b 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -480,6 +480,25 @@ static void __init e820_reserve_setup_data(void)
>  	e820_print_map("reserve setup_data");
>  }
>  
> +#ifdef CONFIG_CRASH_DUMP
> +static void __init e820_crashdump_remove_ram(void)
> +{

... if you move this ifdef/endif within the { } of the function, then
we'll have one less ugly ifdef set below at the call site.

I'll leave the real technical review for Peter, who understands this
area better than I ever will.

Thanks,
Paul.
--

> +	/*
> +	 * We are doing a crash dump, so remove all RAM ranges
> +	 * as they are the ones that need to be dumped.
> +	 * We still need all non-RAM information in order to do I/O.
> +	 */
> +	/* NOTE: if you use old kexec, please remove memmap=exactmap
> +	 * which remove all ranges, not only RAM ranges.
> +	 */
> +	saved_max_pfn = e820_end_of_ram_pfn();
> +	e820_remove_range(0, ULLONG_MAX, E820_RAM, 1);
> +	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
> +	printk(KERN_INFO "crash dump non-RAM map:\n");
> +	e820_print_map("crash_dump");
> +}
> +#endif
> +
>  static void __init memblock_x86_reserve_range_setup_data(void)
>  {
>  	struct setup_data *data;
> @@ -751,6 +770,9 @@ void __init setup_arch(char **cmdline_p)
>  	parse_setup_data();
>  	/* update the e820_saved too */
>  	e820_reserve_setup_data();
> +#ifdef CONFIG_CRASH_DUMP
> +	e820_crashdump_remove_ram();
> +#endif
>  
>  	copy_edd();
>  
> -- 
> 1.7.6
> 
> Best Regards!
> 
> Jun Zhang
> Inet: 8821-4273
> Dir.Tel: 86-21-6116-4273
> Email: jun.zhang@intel.com
> 
> 
> -----Original Message-----
> From: H. Peter Anvin [mailto:hpa@zytor.com] 
> Sent: Thursday, November 01, 2012 12:20 PM
> To: Zhang, Jun
> Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).
> 
> 2) would make most sense to me, but I'd be okay with 3) as well.
> 
> "Zhang, Jun" <jun.zhang@intel.com> wrote:
> 
> >Hello, Anvin
> >
> >I want to explain why I modify in this place. In kexec, it pass three 
> >parameters, memmap=exactmap memmap=544K@64K memmap=64964K@32768K I 
> >think my patch modify the least code.
> >Actually, there are some choise to fix it. 
> >1)  my patch.
> >2)  modify kexec, only pass two parameters -- memmap=544K@64K 
> >memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM 
> >range.
> >3)  add extra optional, like memmap=REMOVERAM
> >
> >Which one do you like? Maybe you have better solution, please share it.
> >Thanks!
> >
> >Best Regards!
> >
> >Jun Zhang
> >Inet: 8821-4273
> >Dir.Tel: 86-21-6116-4273
> >Email: jun.zhang@intel.com
> >
> >-----Original Message-----
> >From: H. Peter Anvin [mailto:hpa@zytor.com]
> >Sent: Wednesday, October 31, 2012 1:39 PM
> >To: Zhang, Jun
> >Cc: Thomas Gleixner; Ingo Molnar; x86@kernel.org; Andrew Morton; 
> >Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org
> >Subject: Re: [PATCH] To crash dump, we need keep other memory type 
> >except E820_RAM, because other type come from BIOS or firmware is used 
> >by other code(for example: PCI_MMCONFIG).
> >
> >On 10/30/2012 10:22 PM, Zhang, Jun wrote:
> >> Hello, Anvin
> >>    You are right. Thanks!
> >>
> >> Hello, All
> >>    Please review it again. Thanks!
> >>
> >>  From bf7506ac7e9ce0df0b915164dbb7a6d858ef2e40 Mon Sep 17 00:00:00
> >> 2001
> >> From: jzha144 <jun.zhang@intel.com>
> >> Date: Wed, 31 Oct 2012 08:51:18 +0800
> >> Subject: [PATCH] When we are doing a crash dump, we still need
> >non-E820_RAM
> >>   memory type address information in order to do I/O. so only
> >>   remove all RAM ranges which need to be dumped.
> >>
> >> Signed-off-by: jzha144 <jun.zhang@intel.com>
> >> ---
> >>   arch/x86/kernel/e820.c |    9 +++++++++
> >>   1 files changed, 9 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index
> >> df06ade..77be839 100644
> >> --- a/arch/x86/kernel/e820.c
> >> +++ b/arch/x86/kernel/e820.c
> >> @@ -851,6 +851,15 @@ static int __init parse_memmap_opt(char *p)
> >>   		 * reset.
> >>   		 */
> >>   		saved_max_pfn = e820_end_of_ram_pfn();
> >> +
> >> +		/*
> >> +		 * We are doing a crash dump, so remove all RAM ranges
> >> +		 * as they are the ones that need to be dumped.
> >> +		 * We still need all non-RAM information in order to do I/O.
> >> +		 */
> >> +		e820_remove_range(0, ULLONG_MAX, E820_RAM, 1);
> >> +		userdef = 1;
> >> +		return 0;
> >>   #endif
> >>   		e820.nr_map = 0;
> >>   		userdef = 1;
> >>
> >
> >The code is still wrong...
> >
> >	-hpa
> >
> >
> >--
> >H. Peter Anvin, Intel Open Source Technology Center I work for Intel. 
> >I don't speak on their behalf.
> 
> --
> Sent from my mobile phone. Please excuse brevity and lack of formatting.

  reply	other threads:[~2012-11-02 15:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-31  1:26 [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG) Zhang, Jun
2012-10-31  2:46 ` H. Peter Anvin
2012-10-31  3:39   ` Zhang, Jun
2012-10-31  4:38     ` H. Peter Anvin
2012-10-31  5:22       ` Zhang, Jun
2012-10-31  5:38         ` H. Peter Anvin
2012-11-01  2:15           ` Zhang, Jun
2012-11-01  4:20             ` H. Peter Anvin
2012-11-01  8:49               ` Zhang, Jun
2012-11-02 15:08                 ` Paul Gortmaker [this message]
2012-11-02 16:37                 ` H. Peter Anvin
2012-11-05  1:37                   ` [PATCH] crash dump: don't delete non-E820_RAM during init Zhang, Jun
2012-11-05  2:39                     ` H. Peter Anvin
2012-11-05  2:57                       ` Zhang, Jun
2012-11-05  2:59                         ` H. Peter Anvin

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=20121102150859.GG25658@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=jun.zhang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@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 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.