lkml.org 
[lkml]   [2009]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] x86: fix system die when load with "reservetop" parameter


    Ingo Molnar wrote:
    > * Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> wrote:
    >
    >> The system will die if the kernel is booted with "reservetop"
    >> parameter, in present code, parse "reservetop" parameter after
    >> early_ioremap_init(), and some function still use early_ioremap()
    >> after it.
    >
    > btw., what are you using the 'reservetop' boot option for?
    >

    Hi Ingo,

    Actually, this bug is detected by my review first, then confirm it by
    loading with "reservetop" parameter

    >> The problem is, "reservetop" parameter can modify 'FIXADDR_TOP',
    >> then the virtual address got by early_ioremap() is base on old
    >> 'FIXADDR_TOP', but the page mapping is base on new 'FIXADDR_TOP',
    >> it will occur page fault, and the IDT is not prepare yet, so, the
    >> system is dead.
    >>
    >> So, put parse_early_param() in the front of early_ioremap_init()
    >> in this patch.
    >>
    >> Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
    >> ---
    >> arch/x86/kernel/setup.c | 10 +++++-----
    >> 1 files changed, 5 insertions(+), 5 deletions(-)
    >
    > Does this bug trigger in 2.6.30 too?
    >
    > I'm quite nervous about doing this change so late in the .31 cycle,
    > we've got a hundred early parameters that now get executed much
    > earlier than before. No way can i test all of them and others
    > testing it (like in your case) takes time to trickle through.
    >
    > So unless this is a .31 regression i'd be inclined to queue it up
    > for .32.
    >

    OK, this parameter is introduced in v2.6.27, but It seems like less
    people use it and no one report this bug before. So, I think we can
    queue it up for .32

    Thanks,
    Xiao


    \
     
     \ /
      Last update: 2009-08-24 03:25    [W:3.429 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site