This is a note to let you know that I've just added the patch titled x86, range: fix missing merge during add range
to the 3.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-range-fix-missing-merge-during-add-range.patch and it can be found in the queue-3.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable@vger.kernel.org> know about it. >From fbe06b7bae7c9cf6ab05168fce5ee93b2f4bae7c Mon Sep 17 00:00:00 2001 From: Yinghai Lu <ying...@kernel.org> Date: Fri, 17 May 2013 11:49:10 -0700 Subject: x86, range: fix missing merge during add range From: Yinghai Lu <ying...@kernel.org> commit fbe06b7bae7c9cf6ab05168fce5ee93b2f4bae7c upstream. 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: [<ffffffff813661df>] 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" <christian.koe...@amd.com> Signed-off-by: Yinghai Lu <ying...@kernel.org> Link: http://lkml.kernel.org/r/cae9fiqvofgosk7q5-0irjkbxemqk729cnd4hov-1qcbjdhx...@mail.gmail.com Signed-off-by: H. Peter Anvin <h...@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- kernel/range.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/kernel/range.c +++ b/kernel/range.c @@ -48,9 +48,11 @@ int add_range_with_merge(struct range *r final_start = min(range[i].start, start); final_end = max(range[i].end, end); - range[i].start = final_start; - range[i].end = final_end; - return nr_range; + /* clear it and add it back for further merge */ + range[i].start = 0; + range[i].end = 0; + return add_range_with_merge(range, az, nr_range, + final_start, final_end); } /* Need to add it: */ Patches currently in stable-queue which might be from ying...@kernel.org are queue-3.9/x86-64-init-fix-a-possible-wraparound-bug-in-switchover-in-head_64.s.patch queue-3.9/x86-range-fix-missing-merge-during-add-range.patch -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html