Re: Regression in efi.c 2.6.32-rc7

[indexer <indexer@internode.on.net>]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

H. Peter Anvin

I am sadly very new to git and its functions but i did the best i could, 
and i had build errors on the last attempt, but i have narrowed this 
down to three commits. Find the out put of git bisect view --stat 
attached with these commits included. Now i may be wrong, but it appears 
that only the commit in realtion to 64 bit memory maps will affect my 
system (as i am running x86_64) . For extra details, it seems that 
commit was to fix an issue with Macbook gen 5 rev 2, where i am using a 
gen 5 rev 3. I will try to finish the bisect once i have received help 
about this build issue.

Your time is appreciated.

Sincerely

William


H. Peter Anvin wrote:
> On 11/17/2009 06:42 AM, indexer wrote:
>   
>> I would like to report a possible regression in efi.c with kernels
>> 2.6.31 , 2.6.32-rc5 and 2.6.32.rc7.
>>
>> Attempting to boot x86_64 with elilo succeeds using 2.6.30 . Using the
>> same config cannot boot with any of the 3 afore mentioned kernels. Elilo
>> freezes at bootloader as system attempts to initiate. Cannot attach a
>> serial console for debug, and no errors appear on screen. No version of
>> refit, elilo, efi firmware changes, only the kernel in question. This
>> results in an unbootable system using efi.
>>
>> I have already followed the patch described here,
>> http://bugzilla.kernel.org/show_bug.cgi?id=14466 , it does not change
>> the situation on 2.6.31 or 2.6.32-rc5, and no need to patch 2.6.32-rc7
>> as it was merged already.
>>
>> The below diff shows the differences in efi.c between 2.6.30 and
>> 2.6.32-rc7. Please also find attached my .config for 2.6.32.rc7
>>
>>     
>
> Can you do a git bisect between 2.6.30 and 2.6.31?
>
> 	-hpa
>
>   


[-- Attachment #2: git-bisect-changes --]
[-- Type: text/plain, Size: 5832 bytes --]

commit fdb8a42742ac95606668f73481dfb2f760658fdd
Author: Roel Kluin <roel.kluin@gmail.com>
Date:   Thu Aug 6 15:58:13 2009 -0700

    x86: fix buffer overflow in efi_init()
    
    If the vendor name (from c16) can be longer than 100 bytes (or missing a
    terminating null), then the null is written past the end of vendor[].
    
    Found with Parfait, http://research.sun.com/projects/parfait/
    
    Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Cc: Huang Ying <ying.huang@intel.com>

 arch/x86/kernel/efi.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

commit 6a7bbd57ed50bb62c9a81ae5f2e202ca689e5964
Author: Paul Mackerras <paulus@samba.org>
Date:   Mon Aug 3 22:38:10 2009 +1000

    x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
    
    Booting current 64-bit x86 kernels on the latest Apple MacBook
    (MacBook5,2) via EFI gives the following warning:
    
    [    0.182209] ------------[ cut here ]------------
    [    0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0()
    [    0.182227] Hardware name: MacBook5,2
    [    0.182231] CPA: called for zero pte. vaddr = ffff8800ffe00000 cpa->vaddr = ffff8800ffe00000
    [    0.182236] Modules linked in:
    [    0.182242] Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #6
    [    0.182246] Call Trace:
    [    0.182254]  [<ffffffff8102c754>] ? __cpa_process_fault+0x44/0xa0
    [    0.182261]  [<ffffffff81048668>] warn_slowpath_common+0x78/0xd0
    [    0.182266]  [<ffffffff81048744>] warn_slowpath_fmt+0x64/0x70
    [    0.182272]  [<ffffffff8102c7ec>] ? update_page_count+0x3c/0x50
    [    0.182280]  [<ffffffff818d25c5>] ? phys_pmd_init+0x140/0x22e
    [    0.182286]  [<ffffffff8102c754>] __cpa_process_fault+0x44/0xa0
    [    0.182292]  [<ffffffff8102ce60>] __change_page_attr_set_clr+0x5f0/0xb40
    [    0.182301]  [<ffffffff810d1035>] ? vm_unmap_aliases+0x175/0x190
    [    0.182307]  [<ffffffff8102d4ae>] change_page_attr_set_clr+0xfe/0x3d0
    [    0.182314]  [<ffffffff8102dcca>] _set_memory_uc+0x2a/0x30
    [    0.182319]  [<ffffffff8102dd4b>] set_memory_uc+0x7b/0xb0
    [    0.182327]  [<ffffffff818afe31>] efi_enter_virtual_mode+0x2ad/0x2c9
    [    0.182334]  [<ffffffff818a1c66>] start_kernel+0x2db/0x3f4
    [    0.182340]  [<ffffffff818a1289>] x86_64_start_reservations+0x99/0xb9
    [    0.182345]  [<ffffffff818a1389>] x86_64_start_kernel+0xe0/0xf2
    [    0.182357] ---[ end trace 4eaa2a86a8e2da22 ]---
    [    0.182982] init_memory_mapping: 00000000ffffc000-0000000100000000
    [    0.182993]  00ffffc000 - 0100000000 page 4k
    
    This happens because the 64-bit version of efi_ioremap calls
    init_memory_mapping for all addresses, regardless of whether they are
    RAM or MMIO.  The EFI tables on this machine ask for runtime access to
    some MMIO regions:
    
    [    0.000000] EFI: mem195: type=11, attr=0x8000000000000000, range=[0x0000000093400000-0x0000000093401000) (0MB)
    [    0.000000] EFI: mem196: type=11, attr=0x8000000000000000, range=[0x00000000ffc00000-0x00000000ffc40000) (0MB)
    [    0.000000] EFI: mem197: type=11, attr=0x8000000000000000, range=[0x00000000ffc40000-0x00000000ffc80000) (0MB)
    [    0.000000] EFI: mem198: type=11, attr=0x8000000000000000, range=[0x00000000ffc80000-0x00000000ffca4000) (0MB)
    [    0.000000] EFI: mem199: type=11, attr=0x8000000000000000, range=[0x00000000ffca4000-0x00000000ffcb4000) (0MB)
    [    0.000000] EFI: mem200: type=11, attr=0x8000000000000000, range=[0x00000000ffcb4000-0x00000000ffffc000) (3MB)
    [    0.000000] EFI: mem201: type=11, attr=0x8000000000000000, range=[0x00000000ffffc000-0x0000000100000000) (0MB)
    
    This arranges to pass the EFI memory type through to efi_ioremap, and
    makes efi_ioremap use ioremap rather than init_memory_mapping if the
    type is EFI_MEMORY_MAPPED_IO.  With this, the above warning goes away.
    
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    LKML-Reference: <19062.55858.533494.471153@cargo.ozlabs.ibm.com>
    Cc: Huang Ying <ying.huang@intel.com>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>

 arch/x86/kernel/efi.c    |    2 +-
 arch/x86/kernel/efi_64.c |    6 +++++-
 2 files changed, 6 insertions(+), 2 deletions(-)

commit e2a7147640a54eb812c8ab5f3ee4424b92db4856
Author: Cliff Wickman <cpw@sgi.com>
Date:   Tue Jun 16 16:43:40 2009 -0500

    x86: correct the conversion of EFI memory types
    
    This patch causes all the EFI_RESERVED_TYPE memory reservations to be recorded
    in the e820 table as type E820_RESERVED.
    
    (This patch replaces one called 'x86: vendor reserved memory type'.
     This version has been discussed a bit with Peter and Yinghai but not given
     a final opinion.)
    
    Without this patch EFI_RESERVED_TYPE memory reservations may be
    marked usable in the e820 table. There may be a collision between
    kernel use and some reserver's use of this memory.
    
    (An example use of this functionality is the UV system, which
     will access extremely large areas of memory with a memory engine
     that allows a user to address beyond the processor's range.  Such
     areas are reserved in the EFI table by the BIOS.
     Some loaders have a restricted number of entries possible in the e820 table,
     hence the need to record the reservations in the unrestricted EFI table.)
    
    The call to do_add_efi_memmap() is only made if "add_efi_memmap" is specified
    on the kernel command line.
    
    Signed-off-by: Cliff Wickman <cpw@sgi.com>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>

 arch/x86/kernel/efi.c |   31 ++++++++++++++++++++++++++++---
 1 files changed, 28 insertions(+), 3 deletions(-)