linux-kernel - Re: linux-next: Tree for Sep 18 (build failures, up to 10/02)

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:	Sat, 10 Oct 2015 17:26:23 +0100
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Guenter Roeck <linux@...ck-us.net>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jonathan Zhang <zjzhang@...eaurora.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matt Fleming <matt.fleming@...el.com>,
	linux-efi@...r.kernel.org, Tony Luck <tony.luck@...il.com>
Subject: Re: linux-next: Tree for Sep 18 (build failures, up to 10/02)

On Sat, 03 Oct, at 11:26:07PM, Matt Fleming wrote:
> 
> Urgh, sorry about this slipping through the cracks Guenter!
> 
> What about fixing it up with this patch?
> 
> ---
> 
> From 85ae872eafef767cf37a0a305266522a62b43fc2 Mon Sep 17 00:00:00 2001
> From: Matt Fleming <matt.fleming@...el.com>
> Date: Sat, 3 Oct 2015 20:44:52 +0100
> Subject: [PATCH] efi: Use the generic efi.memmap instead of 'memmap'
> 
> Guenter reports that commit 7bf793115dd9 ("efi, x86: Rearrange
> efi_mem_attributes()") breaks ia64 compilation with the following
> error,
> 
>  drivers/built-in.o: In function `efi_mem_attributes':
>   (.text+0xde962): undefined reference to `memmap'
>  drivers/built-in.o: In function `efi_mem_attributes':
>   (.text+0xde971): undefined reference to `memmap'
> 
> Instead of using the (rather poorly named) global variable 'memmap'
> which doesn't exist on ia64, use efi.memmap which points to the
> 'memmap' object on x86 and arm64 and which is NULL for ia64.
> 
> The fact that efi.memmap is NULL for ia64 is OK because ia64 provides
> its own implementation of efi_mem_attributes().
> 
> Reported-by: Guenter Roeck <linux@...ck-us.net>
> Cc: Jonathan Zhang <zjzhang@...eaurora.org>
> Cc: Ingo Molnar <mingo@...nel.org>
> Cc: Tony Luck <tony.luck@...el.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>
> Signed-off-by: Matt Fleming <matt.fleming@...el.com>
> ---
>  drivers/firmware/efi/efi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index dd153be03f56..335f4c1a1504 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -647,13 +647,15 @@ char * __init efi_md_typeattr_format(char *buf, size_t size,
>   */
>  u64 __weak efi_mem_attributes(unsigned long phys_addr)
>  {
> +	struct efi_memory_map *map;
>  	efi_memory_desc_t *md;
>  	void *p;
>  
>  	if (!efi_enabled(EFI_MEMMAP))
>  		return 0;
>  
> -	for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> +	map = efi.memmap;
> +	for (p = map->map; p < map->map_end; p += map->desc_size) {
>  		md = p;
>  		if ((md->phys_addr <= phys_addr) &&
>  		    (phys_addr < (md->phys_addr +

tip folks, could you pick this up to fix the ia64 breakage in
linux-next?

-- 
Matt Fleming, Intel Open Source Technology Center
--
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/