[PATCH 2/2] makedumpfile: Use max_pfn from mem_map array

HATAYAMA Daisuke d.hatayama at jp.fujitsu.com
Wed Mar 26 05:55:07 EDT 2014


From: Michael Holzheu <holzheu at linux.vnet.ibm.com>
Subject: [PATCH 2/2] makedumpfile: Use max_pfn from mem_map array
Date: Tue, 25 Mar 2014 17:14:20 +0100

> There are dump mechansims like s390 stand-alond dump or KVM virsh dump
> that write the physical memory of a machine and are not aware of the
> dumped operating system. For those dump mechanisms it can happen
> that for the Linux kernel of the dumped system the "mem=" kernel
> parameter has been specified. In this case max_mapnr that makedumpfile
> gets from the ELF header can be bigger than the maximum page frame number
> used by the dumped Linux kernel.
> 
> With this patch makedumpfile gets the maximum page frame number from
> the mem_map array and adjusts info->max_mapnr if this value is smaller
> than the value calculated from the ELF header.
> 
> Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com>
> ---
>  makedumpfile.c |   14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -2829,7 +2829,8 @@ get_mem_map_without_mm(void)
>  int
>  get_mem_map(void)
>  {
> -	int ret;
> +	unsigned long max_pfn = 0;
> +	int ret, i;

Please define max_pfn as unsigned long long.

And for i,

>  
>  	switch (get_mem_type()) {
>  	case SPARSEMEM:
> @@ -2861,6 +2862,17 @@ get_mem_map(void)
>  		ret = FALSE;
>  		break;
>  	}
> +	/*
> +	 * Adjust "max_mapnr" for the case that Linux uses less memory
> +	 * than is dumped. For example when "mem=" has been used for the
> +	 * dumped system.
> +	 */
> +	for (i = 0; i < info->num_mem_map; i++) {

info->num_mem_map is defined as unsigned int. I guess some warning
about comparison with different signedness occurs.

> +		if (info->mem_map_data[i].mem_map == NOT_MEMMAP_ADDR)
> +			continue;
> +		max_pfn = MAX(max_pfn, info->mem_map_data[i].pfn_end);
> +	}
> +	info->max_mapnr = MIN(info->max_mapnr, max_pfn);
>  	return ret;
>  }
>  
> 

Thanks.
HATAYAMA, Daisuke




More information about the kexec mailing list