linux-kernel - [PATCH 3/7] powerpc: Use more accurate limit for first segment memory allocations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20110307114839.GE8194@linux.vnet.ibm.com>
Date:	Mon, 7 Mar 2011 17:18:39 +0530
From:	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
To:	stable@...nel.org
Cc:	linux-kernel@...r.kernel.org, greg@...ah.com, anton@...ba.org,
	benh@...nel.crashing.org
Subject: [PATCH 3/7] powerpc: Use more accurate limit for first segment
	memory allocations

    powerpc: Use more accurate limit for first segment memory allocations

    Commit: 095c7965f4dc870ed2b65143b1e2610de653416c upstream

    On large machines we are running out of room below 256MB. In some cases we
    only need to ensure the allocation is in the first segment, which may be
    256MB or 1TB.

    Add slb0_limit and use it to specify the upper limit for the irqstack and
    emergency stacks.

    On a large ppc64 box, this fixes a panic at boot when the crashkernel=
    option is specified (previously we would run out of memory below 256MB).

    Signed-off-by: Milton Miller <miltonm@....com>
    Signed-off-by: Anton Blanchard <anton@...ba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@...nel.crashing.org>
    Signed-off-by: Kamalesh babulal <kamalesh@...ux.vnet.ibm.com>
---
 arch/powerpc/kernel/setup_64.c |   17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

Index: b/arch/powerpc/kernel/setup_64.c
===================================================================
--- a/arch/powerpc/kernel/setup_64.c	2011-03-07 00:31:51.559273335 -0800
+++ b/arch/powerpc/kernel/setup_64.c	2011-03-07 02:12:58.681888270 -0800
@@ -432,9 +432,18 @@
	DBG(" <- setup_system()\n");
 }

+static u64 slb0_limit(void)
+{
+	if (cpu_has_feature(CPU_FTR_1T_SEGMENT))
+		return 1UL << SID_SHIFT_1T;
+
+       return 1UL << SID_SHIFT;
+}
+
 #ifdef CONFIG_IRQSTACKS
 static void __init irqstack_early_init(void)
 {
+	u64 limit = slb0_limit();
	unsigned int i;

	/*
@@ -444,10 +453,10 @@
	for_each_possible_cpu(i) {
		softirq_ctx[i] = (struct thread_info *)
			__va(lmb_alloc_base(THREAD_SIZE,
-					    THREAD_SIZE, 0x10000000));
+					    THREAD_SIZE, limit));
		hardirq_ctx[i] = (struct thread_info *)
			__va(lmb_alloc_base(THREAD_SIZE,
-					    THREAD_SIZE, 0x10000000));
+					    THREAD_SIZE, limit));
	}
 }
 #else
@@ -478,7 +487,7 @@
  */
 static void __init emergency_stack_init(void)
 {
-	unsigned long limit;
+	u64 limit;
	unsigned int i;

	/*
@@ -490,7 +499,7 @@
	 * bringup, we need to get at them in real mode. This means they
	 * must also be within the RMO region.
	 */
-	limit = min(0x10000000ULL, lmb.rmo_size);
+	limit = min(slb0_limit(), lmb.rmo_size);

	for_each_possible_cpu(i) {
		unsigned long sp;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/