15 Jul, 2011

2 commits

  • Other than sanity check and debug message, the x86 specific version of
    memblock reserve/free functions are simple wrappers around the generic
    versions - memblock_reserve/free().

    This patch adds debug messages with caller identification to the
    generic versions and replaces x86 specific ones and kills them.
    arch/x86/include/asm/memblock.h and arch/x86/mm/memblock.c are empty
    after this change and removed.

    Signed-off-by: Tejun Heo
    Link: http://lkml.kernel.org/r/1310462166-31469-14-git-send-email-tj@kernel.org
    Cc: Yinghai Lu
    Cc: Benjamin Herrenschmidt
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Signed-off-by: H. Peter Anvin

    Tejun Heo
     
  • setup_bios_corruption_check() and memtest do_one_pass() open code
    memblock free area iteration using memblock_x86_find_in_range_size().
    Convert them to use for_each_free_mem_range() instead.

    This leaves memblock_x86_find_in_range_size() and
    memblock_x86_check_reserved_size() unused. Kill them.

    Signed-off-by: Tejun Heo
    Link: http://lkml.kernel.org/r/1310462166-31469-8-git-send-email-tj@kernel.org
    Cc: Yinghai Lu
    Cc: Benjamin Herrenschmidt
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Signed-off-by: H. Peter Anvin

    Tejun Heo
     

14 Jul, 2011

1 commit

  • 25818f0f28 (memblock: Make MEMBLOCK_ERROR be 0) thankfully made
    MEMBLOCK_ERROR 0 and there already are codes which expect error return
    to be 0. There's no point in keeping MEMBLOCK_ERROR around. End its
    misery.

    Signed-off-by: Tejun Heo
    Link: http://lkml.kernel.org/r/1310457490-3356-6-git-send-email-tj@kernel.org
    Cc: Yinghai Lu
    Cc: Benjamin Herrenschmidt
    Signed-off-by: H. Peter Anvin

    Tejun Heo
     

09 Mar, 2011

1 commit


28 Aug, 2010

1 commit

  • 1. replace find_e820_area with memblock_find_in_range
    2. replace reserve_early with memblock_x86_reserve_range
    3. replace free_early with memblock_x86_free_range.
    4. NO_BOOTMEM will switch to use memblock too.
    5. use _e820, _early wrap in the patch, in following patch, will
    replace them all
    6. because memblock_x86_free_range support partial free, we can remove some special care
    7. Need to make sure that memblock_find_in_range() is called after memblock_x86_fill()
    so adjust some calling later in setup.c::setup_arch()
    -- corruption_check and mptable_update

    -v2: Move reserve_brk() early
    Before fill_memblock_area, to avoid overlap between brk and memblock_find_in_range()
    that could happen We have more then 128 RAM entry in E820 tables, and
    memblock_x86_fill() could use memblock_find_in_range() to find a new place for
    memblock.memory.region array.
    and We don't need to use extend_brk() after fill_memblock_area()
    So move reserve_brk() early before fill_memblock_area().
    -v3: Move find_smp_config early
    To make sure memblock_find_in_range not find wrong place, if BIOS doesn't put mptable
    in right place.
    -v4: Treat RESERVED_KERN as RAM in memblock.memory. and they are already in
    memblock.reserved already..
    use __NOT_KEEP_MEMBLOCK to make sure memblock related code could be freed later.
    -v5: Generic version __memblock_find_in_range() is going from high to low, and for 32bit
    active_region for 32bit does include high pages
    need to replace the limit with memblock.default_alloc_limit, aka get_max_mapped()
    -v6: Use current_limit instead
    -v7: check with MEMBLOCK_ERROR instead of -1ULL or -1L
    -v8: Set memblock_can_resize early to handle EFI with more RAM entries
    -v9: update after kmemleak changes in mainline

    Suggested-by: David S. Miller
    Suggested-by: Benjamin Herrenschmidt
    Suggested-by: Thomas Gleixner
    Signed-off-by: Yinghai Lu
    Signed-off-by: H. Peter Anvin

    Yinghai Lu
     

15 Mar, 2009

1 commit

  • Impact: fix boot crash

    Need to exit early if the addr is far above 64k.

    The crash got exposed by:

    78a8b35: x86: make e820_update_range() handle small range update

    Signed-off-by: Yinghai Lu
    Cc:
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

13 Mar, 2009

1 commit

  • Impact: fix crashes under Xen due to unrobust e820 code

    find_e820_area_size() must return a properly distinguishable and
    out-of-bounds value when it fails, and -1UL does not meet that
    criteria on i386/PAE. Additionally, callers of the function must
    check against that value.

    early_reserve_e820() should be prepared for the region found to be
    outside of the addressable range on 32-bits.

    e820_update_range_map() should not blindly update e820, but should do
    all it work on the map it got a pointer passed for (which in 50% of the
    cases is &e820_saved). It must also not call e820_add_region(), as that
    again acts on e820 unconditionally.

    The issues were found when trying to make this option work in our Xen
    kernel (i.e. where some of the silent assumptions made in the code
    would not hold).

    Signed-off-by: Jan Beulich
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Jan Beulich
     

28 Oct, 2008

3 commits