17 Jan, 2015

1 commit

  • Avoid overflow possibility.

    [ The overflow is purely theoretical, since this is used for memory
    ranges that aren't even close to using the full 64 bits, but this is
    the right thing to do regardless. - Linus ]

    Signed-off-by: Louis Langholtz
    Cc: Yinghai Lu
    Cc: Peter Anvin
    Cc: Andrew Morton
    Signed-off-by: Linus Torvalds

    Louis Langholtz
     

19 Jun, 2013

1 commit

  • Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge
    during add range) broke mtrr cleanup on his setup in 3.9.5.
    corresponding commit in upstream is fbe06b7bae7c.

    The reason is add_range_with_merge could generate blank spot.

    We could avoid that by searching new expanded start/end, that
    new range should include all connected ranges in range array.
    At last add the new expanded start/end to the range array.
    Also move up left array so do not add new blank slot in the
    range array.

    -v2: move left array to avoid enhance add_range()
    -v3: include fix from Joshua about memmove declaring when
    DYN_DEBUG is used.

    Reported-by: Joshua Covington
    Tested-by: Joshua Covington
    Signed-off-by: Yinghai Lu
    Link: http://lkml.kernel.org/r/1371154622-8929-3-git-send-email-yinghai@kernel.org
    Cc: v3.9
    Signed-off-by: H. Peter Anvin

    Yinghai Lu
     

18 May, 2013

1 commit

  • Christian found v3.9 does not work with E350 with EFI is enabled.

    [ 1.658832] Trying to unpack rootfs image as initramfs...
    [ 1.679935] BUG: unable to handle kernel paging request at ffff88006e3fd000
    [ 1.686940] IP: [] memset+0x1f/0xb0
    [ 1.692010] PGD 1f77067 PUD 1f7a067 PMD 61420067 PTE 0

    but early memtest report all memory could be accessed without problem.

    early page table is set in following sequence:
    [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
    [ 0.000000] init_memory_mapping: [mem 0x6e600000-0x6e7fffff]
    [ 0.000000] init_memory_mapping: [mem 0x6c000000-0x6e5fffff]
    [ 0.000000] init_memory_mapping: [mem 0x00100000-0x6bffffff]
    [ 0.000000] init_memory_mapping: [mem 0x6e800000-0x6ea07fff]
    but later efi_enter_virtual_mode try set mapping again wrongly.
    [ 0.010644] pid_max: default: 32768 minimum: 301
    [ 0.015302] init_memory_mapping: [mem 0x640c5000-0x6e3fcfff]
    that means it fails with pfn_range_is_mapped.

    It turns out that we have a bug in add_range_with_merge and it does not
    merge range properly when new add one fill the hole between two exsiting
    ranges. In the case when [mem 0x00100000-0x6bffffff] is the hole between
    [mem 0x00000000-0x000fffff] and [mem 0x6c000000-0x6e7fffff].

    Fix the add_range_with_merge by calling itself recursively.

    Reported-by: "Christian König"
    Signed-off-by: Yinghai Lu
    Link: http://lkml.kernel.org/r/CAE9FiQVofGoSk7q5-0irjkBxemqK729cND4hov-1QCBJDhxpgQ@mail.gmail.com
    Cc: v3.9
    Signed-off-by: H. Peter Anvin

    Yinghai Lu
     

01 May, 2013

1 commit


31 Oct, 2011

1 commit


12 Nov, 2010

1 commit

  • clean_sort_range() should return a number of nonempty elements of range
    array, but if the array is full clean_sort_range() returns 0.

    The problem is that the number of nonempty elements is evaluated by
    finding the first empty element of the array. If there is no such element
    it returns an initial value of local variable nr_range that is zero.

    The fix is trivial: it changes initial value of nr_range to size of the
    array.

    The bug can lead to loss of information regarding all ranges, since
    typically returned value of clean_sort_range() is considered as an actual
    number of ranges in the array after a series of add/subtract operations.

    Found by Analytical Verification project of Linux Verification Center
    (linuxtesting.org), thanks to Alexander Kolosov.

    Signed-off-by: Alexey Khoroshilov
    Cc: Yinghai Lu
    Cc: "H. Peter Anvin"
    Cc: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Khoroshilov
     

10 Aug, 2010

1 commit


11 Feb, 2010

2 commits

  • So make interface more consistent with early_res.
    Later we can share some code with early_res.

    Signed-off-by: Yinghai Lu
    LKML-Reference:
    Signed-off-by: H. Peter Anvin

    Yinghai Lu
     
  • We have almost the same code for mtrr cleanup and amd_bus checkup, and
    this code will also be used in replacing bootmem with early_res,
    so try to move them together and reuse it from different parts.

    Also rename update_range to subtract_range as that is what the
    function is actually doing.

    -v2: update comments as Christoph requested

    Signed-off-by: Yinghai Lu
    LKML-Reference:
    Signed-off-by: H. Peter Anvin

    Yinghai Lu