linux-kernel - Re: [PATCH v3 15/17] x86/kexec: Remove walk_iomem

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]

Message-ID: <20160107123738.GA2870@dhcp-128-65.nay.redhat.com>
Date:	Thu, 7 Jan 2016 20:37:38 +0800
From:	Dave Young <dyoung@...hat.com>
To:	Toshi Kani <toshi.kani@....com>
Cc:	akpm@...ux-foundation.org, bp@...en8.de,
	linux-arch@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Minfei Huang <mhuang@...hat.com>,
	x86@...nel.org, kexec@...ts.infradead.org
Subject: Re: [PATCH v3 15/17] x86/kexec: Remove walk_iomem_res() call with
 GART

On 01/05/16 at 11:54am, Toshi Kani wrote:
> There is no longer any driver inserting a "GART" region in the kernel
> since 'commit 707d4eefbdb3 ("Revert "[PATCH] Insert GART region into
> resource map"")' was made.
> 
> Remove the call to walk_iomem_res() with "GART", its callback function,
> and GART-specific variables set by the callback.
> 
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: Dave Young <dyoung@...hat.com>
> Cc: Minfei Huang <mhuang@...hat.com>
> Cc: x86@...nel.org
> Cc: kexec@...ts.infradead.org
> Link: http://lkml.kernel.org/r/<20160104110427.GA2965@...p-128-65.nay.redhat.com>
> Signed-off-by: Toshi Kani <toshi.kani@....com>
> ---
>  arch/x86/kernel/crash.c |   37 +------------------------------------
>  1 file changed, 1 insertion(+), 36 deletions(-)
> 
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 082373b..f5069e7 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -56,10 +56,9 @@ struct crash_elf_data {
>  	struct kimage *image;
>  	/*
>  	 * Total number of ram ranges we have after various adjustments for
> -	 * GART, crash reserved region etc.
> +	 * crash reserved region, etc.
>  	 */
>  	unsigned int max_nr_ranges;
> -	unsigned long gart_start, gart_end;
>  
>  	/* Pointer to elf header */
>  	void *ehdr;
> @@ -190,17 +189,6 @@ static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
>  	return 0;
>  }
>  
> -static int get_gart_ranges_callback(u64 start, u64 end, void *arg)
> -{
> -	struct crash_elf_data *ced = arg;
> -
> -	ced->gart_start = start;
> -	ced->gart_end = end;
> -
> -	/* Not expecting more than 1 gart aperture */
> -	return 1;
> -}
> -
>  
>  /* Gather all the required information to prepare elf headers for ram regions */
>  static void fill_up_crash_elf_data(struct crash_elf_data *ced,
> @@ -215,22 +203,6 @@ static void fill_up_crash_elf_data(struct crash_elf_data *ced,
>  
>  	ced->max_nr_ranges = nr_ranges;
>  
> -	/*
> -	 * We don't create ELF headers for GART aperture as an attempt
> -	 * to dump this memory in second kernel leads to hang/crash.
> -	 * If gart aperture is present, one needs to exclude that region
> -	 * and that could lead to need of extra phdr.
> -	 */
> -	walk_iomem_res("GART", IORESOURCE_MEM, 0, -1,
> -				ced, get_gart_ranges_callback);
> -
> -	/*
> -	 * If we have gart region, excluding that could potentially split
> -	 * a memory range, resulting in extra header. Account for  that.
> -	 */
> -	if (ced->gart_end)
> -		ced->max_nr_ranges++;
> -
>  	/* Exclusion of crash region could split memory ranges */
>  	ced->max_nr_ranges++;
>  
> @@ -339,13 +311,6 @@ static int elf_header_exclude_ranges(struct crash_elf_data *ced,
>  			return ret;
>  	}
>  
> -	/* Exclude GART region */
> -	if (ced->gart_end) {
> -		ret = exclude_mem_range(cmem, ced->gart_start, ced->gart_end);
> -		if (ret)
> -			return ret;
> -	}
> -
>  	return ret;
>  }
>  

Reviewed-by: Dave Young <dyoung@...hat.com>

Thanks
Dave
--
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/