linux-kernel - Re: [PATCH] x86_64: setup saved_max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 2 Nov 2006 09:28:12 -0500
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Magnus Damm <magnus@...inux.co.jp>
Cc:	linux-kernel@...r.kernel.org, Mel Gorman <mel@....ul.ie>,
	Andi Kleen <ak@....de>, magnus.damm@...il.com,
	fastboot@...ts.osdl.org
Subject: Re: [PATCH] x86_64: setup saved_max_pfn correctly (kdump)

On Thu, Nov 02, 2006 at 10:19:34PM +0900, Magnus Damm wrote:
> x86_64: setup saved_max_pfn correctly
> 
> 2.6.19-rc4 has broken CONFIG_CRASH_DUMP support on x86_64. It is impossible 
> to read out the kernel contents from /proc/vmcore because saved_max_pfn is set
> to zero instead of the max_pfn value before the user map is setup.
> 
> This happens because saved_max_pfn is initialized at parse_early_param() time,
> and at this time no active regions have been registered. save_max_pfn is setup
> from e820_end_of_ram(), more exact find_max_pfn_with_active_regions() which
> returns 0 because no regions exist.
> 
> This patch fixes this by registering before and removing after the call
> to e820_end_of_ram().
> 
> Signed-off-by: Magnus Damm <magnus@...inux.co.jp>
> ---
> 
>  Applies to 2.6.19-rc4.
> 
>  arch/x86_64/kernel/e820.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> --- 0002/arch/x86_64/kernel/e820.c
> +++ work/arch/x86_64/kernel/e820.c	2006-11-02 21:37:19.000000000 +0900
> @@ -594,7 +594,9 @@ static int __init parse_memmap_opt(char 
>  		 * size before original memory map is
>  		 * reset.
>  		 */
> +		e820_register_active_regions(0, 0, -1UL);
>  		saved_max_pfn = e820_end_of_ram();
> +		remove_all_active_ranges();
>  #endif
>  		end_pfn_map = 0;
>  		e820.nr_map = 0;

This looks fine to me for the time being.

Down the line I am thinking that how about passing saved_max_pfn as
command line parameter. I think that way we don't have to pass all the
memmap= options to second kernel and kexec-tools can pass the memory map
through parameter segment. This memory map can be modified to represent
only the memory which can be used by second kernel and not the whole of
the memory.

I think this will simplify the logic and also save us precious comand
line in second kernel for kdump purposes.

Thanks
Vivek
 

  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/