From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:49829 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932382AbcJZJ1e (ORCPT ); Wed, 26 Oct 2016 05:27:34 -0400 Subject: Patch "x86/e820: Don't merge consecutive E820_PRAM ranges" has been added to the 4.4-stable tree To: dan.j.williams@intel.com, bp@alien8.de, brgerst@gmail.com, david@fromorbit.com, dvlasenk@redhat.com, gregkh@linuxfoundation.org, hpa@zytor.com, jmoyer@redhat.com, jpoimboe@redhat.com, luto@kernel.org, mingo@kernel.org, peterz@infradead.org, tglx@linutronix.de, torvalds@linux-foundation.org, yizhan@redhat.com Cc: , From: Date: Wed, 26 Oct 2016 11:26:51 +0200 Message-ID: <147747401116820@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled x86/e820: Don't merge consecutive E820_PRAM ranges to the 4.4-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-e820-don-t-merge-consecutive-e820_pram-ranges.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From 23446cb66c073b827779e5eb3dec301623299b32 Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Wed, 12 Oct 2016 11:01:48 -0700 Subject: x86/e820: Don't merge consecutive E820_PRAM ranges From: Dan Williams commit 23446cb66c073b827779e5eb3dec301623299b32 upstream. Commit: 917db484dc6a ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation") ... fixed up the broken manipulations of max_pfn in the presence of E820_PRAM ranges. However, it also broke the sanitize_e820_map() support for not merging E820_PRAM ranges. Re-introduce the enabling to keep resource boundaries between consecutive defined ranges. Otherwise, for example, an environment that boots with memmap=2G!8G,2G!10G will end up with a single 4G /dev/pmem0 device instead of a /dev/pmem0 and /dev/pmem1 device 2G in size. Reported-by: Dave Chinner Signed-off-by: Dan Williams Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jeff Moyer Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Zhang Yi Cc: linux-nvdimm@lists.01.org Fixes: 917db484dc6a ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation") Link: http://lkml.kernel.org/r/147629530854.10618.10383744751594021268.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/e820.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -347,7 +347,7 @@ int __init sanitize_e820_map(struct e820 * continue building up new bios map based on this * information */ - if (current_type != last_type) { + if (current_type != last_type || current_type == E820_PRAM) { if (last_type != 0) { new_bios[new_bios_entry].size = change_point[chgidx]->addr - last_addr; Patches currently in stable-queue which might be from dan.j.williams@intel.com are queue-4.4/acpi-nfit-check-for-the-correct-event-code-in-notifications.patch queue-4.4/x86-e820-don-t-merge-consecutive-e820_pram-ranges.patch