stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: kirill.shutemov@linux.intel.com, akpm@linux-foundation.org,
	bjorn.andersson@linaro.org, dan.rue@linaro.org,
	gregkh@linuxfoundation.org, mingo@kernel.org,
	naresh.kamboju@linaro.org, peterz@infradead.org,
	sudeep.holla@arm.com, tglx@linutronix.de,
	torvalds@linux-foundation.org, will.deacon@arm.com
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y" has been added to the 4.14-stable tree
Date: Fri, 22 Dec 2017 16:02:33 +0100	[thread overview]
Message-ID: <151395495376229@kroah.com> (raw)


This is a note to let you know that I've just added the patch titled

    mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y

to the 4.14-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:
     mm-sparsemem-fix-arm64-boot-crash-when-config_sparsemem_extreme-y.patch
and it can be found in the queue-4.14 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 629a359bdb0e0652a8227b4ff3125431995fec6e Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Date: Tue, 7 Nov 2017 11:33:37 +0300
Subject: mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y

From: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

commit 629a359bdb0e0652a8227b4ff3125431995fec6e upstream.

Since commit:

  83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y")

we allocate the mem_section array dynamically in sparse_memory_present_with_active_regions(),
but some architectures, like arm64, don't call the routine to initialize sparsemem.

Let's move the initialization into memory_present() it should cover all
architectures.

Reported-and-tested-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y")
Link: http://lkml.kernel.org/r/20171107083337.89952-1-kirill.shutemov@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Dan Rue <dan.rue@linaro.org>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/page_alloc.c |   10 ----------
 mm/sparse.c     |   10 ++++++++++
 2 files changed, 10 insertions(+), 10 deletions(-)

--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5651,16 +5651,6 @@ void __init sparse_memory_present_with_a
 	unsigned long start_pfn, end_pfn;
 	int i, this_nid;
 
-#ifdef CONFIG_SPARSEMEM_EXTREME
-	if (!mem_section) {
-		unsigned long size, align;
-
-		size = sizeof(struct mem_section) * NR_SECTION_ROOTS;
-		align = 1 << (INTERNODE_CACHE_SHIFT);
-		mem_section = memblock_virt_alloc(size, align);
-	}
-#endif
-
 	for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, &this_nid)
 		memory_present(this_nid, start_pfn, end_pfn);
 }
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -207,6 +207,16 @@ void __init memory_present(int nid, unsi
 {
 	unsigned long pfn;
 
+#ifdef CONFIG_SPARSEMEM_EXTREME
+	if (unlikely(!mem_section)) {
+		unsigned long size, align;
+
+		size = sizeof(struct mem_section) * NR_SECTION_ROOTS;
+		align = 1 << (INTERNODE_CACHE_SHIFT);
+		mem_section = memblock_virt_alloc(size, align);
+	}
+#endif
+
 	start &= PAGE_SECTION_MASK;
 	mminit_validate_memmodel_limits(&start, &end);
 	for (pfn = start; pfn < end; pfn += PAGES_PER_SECTION) {


Patches currently in stable-queue which might be from kirill.shutemov@linux.intel.com are

queue-4.14/mm-sparsemem-fix-arm64-boot-crash-when-config_sparsemem_extreme-y.patch
queue-4.14/x86-xen-provide-pre-built-page-tables-only-for-config_xen_pv-y-and-config_xen_pvh-y.patch
queue-4.14/x86-xen-drop-5-level-paging-support-code-from-the-xen_pv-code.patch
queue-4.14/x86-kasan-use-the-same-shadow-offset-for-4-and-5-level-paging.patch
queue-4.14/mm-sparsemem-allocate-mem_section-at-runtime-for-config_sparsemem_extreme-y.patch
queue-4.14/x86-mm-relocate-page-fault-error-codes-to-traps.h.patch

                 reply	other threads:[~2017-12-22 15:02 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=151395495376229@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=dan.rue@linaro.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=mingo@kernel.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=peterz@infradead.org \
    --cc=stable-commits@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).