On 29 January 2016 at 15:00, Mark Salter <msalter@xxxxxxxxxx> wrote: > Hi Ard, > > I ran into an issue with your MEMBLOCK_NOMAP changes on a particular > firmware. The symptom is the kernel panics at boot time when it hits > an unmapped page while unpacking the initramfs. As it turns out, the > start of the initramfs shares a 64k kernel page with the UEFI memmap. > I can avoid the problem with: > > @@ -203,7 +203,7 @@ 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))); > + memblock_reserve(params.mmap & PAGE_MASK, > + PAGE_ALIGN(params.mmap_size + > + (params.mmap & ~PAGE_MASK))); > } > > > But it makes me worry about the same potential problem with > other reserved regions which we nomap. What do you think? > So I take it this initramfs allocation is not made by the stub but by GRUB? Since the stub rounds all allocations to 64 KB ... In any case, regardless of the underlying cause, if any part of the initramfs turns out not to be covered by the linear mapping, we should invoke your code to move it. So I think it should be a matter of refining the logic in relocate_initrd() to do the right thing in this case Your suggested change will break 32-bit ARM, since we use ioremap_nocache() to map the UEFI memory map, and ARM does not allow that on ranges that are part of the linear mapping. -- Ard. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
