Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756775AbcCWUla (ORCPT ); Wed, 23 Mar 2016 16:41:30 -0400 Received: from mail-io0-f181.google.com ([209.85.223.181]:35481 "EHLO mail-io0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752799AbcCWUl3 (ORCPT ); Wed, 23 Mar 2016 16:41:29 -0400 MIME-Version: 1.0 In-Reply-To: <1458762438.23434.120.camel@redhat.com> References: <1454373031-24218-1-git-send-email-msalter@redhat.com> <1458762438.23434.120.camel@redhat.com> Date: Wed, 23 Mar 2016 21:41:28 +0100 Message-ID: Subject: Re: [PATCH] arm64: handle unmapped pages in initrd relocation From: Ard Biesheuvel To: Mark Salter Cc: Catalin Marinas , Will Deacon , Mark Langsdorf , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3449 Lines: 72 On 23 March 2016 at 20:47, Mark Salter wrote: > On Mon, 2016-02-01 at 19:30 -0500, Mark Salter wrote: >> Commit 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as >> MEMBLOCK_NOMAP") causes a potential problem in arm64 initrd relocation >> code. If the kernel uses a pagesize greater than the 4k pagesize used >> by UEFI, pagesize rounding may lead to one or both ends of the initrd >> image to be marked unmapped. This leads to a panic when the kernel goes >> to unpack it. This patch looks for unmapped pages at beginning and end >> of the initrd image and if seen, relocated the initrd to a new area >> completely covered by the kernel linear map. >> >> Signed-off-by: Mark Salter >> Cc: Ard Biesheuvel >> --- > > The Fedora folks have run into this problem with a certain kernel build. What ever > happened to Ard's suggested fix. The MEMBLOCK_NOMAP patch caused a regression which > should be fixed. Whether this patch, Ard's patch, or something else. > > https://bugzilla.redhat.com/show_bug.cgi?id=1309147 > As I mentioned before, reverting the MEMBLOCK_NOMAP patch will break ARM. However, I have some patches in flight [1] that I expect Russell to pick up for v4.7, which will make memremap() work as expected on ARM. So for the v4.7 timeframe, we can fix it properly, by switching to the now fully functional memremap() for mapping the UEFI memory map, which means we can revert the MEMBLOCK_NOMAP change since memremap() doesn't care about that (unlike ioremap_cache(), which disallows mapping normal memory on ARM) That does not fix the breakage, though. Since the issue only occurs on 64k pages kernels, which implies arm64, we can perhaps apply the patch below, and revert to using memblock_reserve() in all cases once [1] is merged. [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/484005 -------8<---------- diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c index 7c5a38c60037..95303d19fff5 100644 --- a/drivers/firmware/efi/arm-init.c +++ b/drivers/firmware/efi/arm-init.c @@ -240,9 +240,25 @@ void __init efi_init(void) reserve_regions(); early_memunmap(memmap.map, params.mmap_size); - memblock_mark_nomap(params.mmap & PAGE_MASK, - PAGE_ALIGN(params.mmap_size + - (params.mmap & ~PAGE_MASK))); + + /* + * On 64k pages kernels, marking the memory map as MEMBLOCK_NOMAP may + * cause adjacent allocations sharing the same 64k page frame to be + * removed from the linear mapping as well. If this happens to cover + * the initrd allocation performed by GRUB (which, unlike the stub, does + * not align its EFI_LOADER_DATA allocations to 64k), we will run into + * trouble later on, since the generic initrd code expects the initrd + * to be covered by the linear mapping. + */ + if (PAGE_SIZE > SZ_4K) { + memblock_reserve(params.mmap & PAGE_MASK, + PAGE_ALIGN(params.mmap_size + + (params.mmap & ~PAGE_MASK))); + } else { + memblock_mark_nomap(params.mmap & PAGE_MASK, + PAGE_ALIGN(params.mmap_size + + (params.mmap & ~PAGE_MASK))); + } init_screen_info(); }