• M
    x86/efi: Fix oops caused by incorrect set_memory_uc() usage · 3e8fa263
    Matt Fleming 提交于
    Calling __pa() with an ioremap'd address is invalid. If we
    encounter an efi_memory_desc_t without EFI_MEMORY_WB set in
    ->attribute we currently call set_memory_uc(), which in turn
    calls __pa() on a potentially ioremap'd address.
    
    On CONFIG_X86_32 this results in the following oops:
    
      BUG: unable to handle kernel paging request at f7f22280
      IP: [<c10257b9>] reserve_ram_pages_type+0x89/0x210
      *pdpt = 0000000001978001 *pde = 0000000001ffb067 *pte = 0000000000000000
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in:
    
      Pid: 0, comm: swapper Not tainted 3.0.0-acpi-efi-0805 #3
       EIP: 0060:[<c10257b9>] EFLAGS: 00010202 CPU: 0
       EIP is at reserve_ram_pages_type+0x89/0x210
       EAX: 0070e280 EBX: 38714000 ECX: f7814000 EDX: 00000000
       ESI: 00000000 EDI: 38715000 EBP: c189fef0 ESP: c189fea8
       DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      Process swapper (pid: 0, ti=c189e000 task=c18bbe60 task.ti=c189e000)
      Stack:
       80000200 ff108000 00000000 c189ff00 00038714 00000000 00000000 c189fed0
       c104f8ca 00038714 00000000 00038715 00000000 00000000 00038715 00000000
       00000010 38715000 c189ff48 c1025aff 38715000 00000000 00000010 00000000
      Call Trace:
       [<c104f8ca>] ? page_is_ram+0x1a/0x40
       [<c1025aff>] reserve_memtype+0xdf/0x2f0
       [<c1024dc9>] set_memory_uc+0x49/0xa0
       [<c19334d0>] efi_enter_virtual_mode+0x1c2/0x3aa
       [<c19216d4>] start_kernel+0x291/0x2f2
       [<c19211c7>] ? loglevel+0x1b/0x1b
       [<c19210bf>] i386_start_kernel+0xbf/0xc8
    
    The only time we can call set_memory_uc() for a memory region is
    when it is part of the direct kernel mapping. For the case where
    we ioremap a memory region we must leave it alone.
    
    This patch reimplements the fix from e8c71062 ("x86, efi:
    Calling __pa() with an ioremap()ed address is invalid") which
    was reverted in e1ad783b because it caused a regression on
    some MacBooks (they hung at boot). The regression was caused
    because the commit only marked EFI_RUNTIME_SERVICES_DATA as
    E820_RESERVED_EFI, when it should have marked all regions that
    have the EFI_MEMORY_RUNTIME attribute.
    
    Despite first impressions, it's not possible to use
    ioremap_cache() to map all cached memory regions on
    CONFIG_X86_64 because of the way that the memory map might be
    configured as detailed in the following bug report,
    
    	https://bugzilla.redhat.com/show_bug.cgi?id=748516
    
    e.g. some of the EFI memory regions *need* to be mapped as part
    of the direct kernel mapping.
    Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
    Cc: Matthew Garrett <mjg@redhat.com>
    Cc: Zhang Rui <rui.zhang@intel.com>
    Cc: Huang Ying <huang.ying.caritas@gmail.com>
    Cc: Keith Packard <keithp@keithp.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1350649546-23541-1-git-send-email-matt@console-pimps.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
    3e8fa263
efi.h 4.3 KB