linux-kernel - [PATCH] mm,x86: limit 32 bit kernel to 12GB memory

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 May 2013 22:46:04 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Pierre-Loup A. Griffais" <pgriffais@...vesoftware.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	sonnyrao@...omium.org,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH] mm,x86: limit 32 bit kernel to 12GB memory

On Wed, 1 May 2013 21:34:26 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> On Mon, Apr 29, 2013 at 08:48:17PM -0400, Rik van Riel wrote:
> > 
> > It could also print out a friendly message, to
> > inform the user they should upgrade to a 64 bit
> > kernel to enjoy the use of all of their memory.
> 
> Oh, oh, oh!!! Can we use my message:
> 
>   http://lwn.net/Articles/501769/
> 
> OK, maybe it's not so friendly ;-)

Here's a somewhat friendlier one. Printing out the total amount of
memory in the system may give them some extra motivation to upgrade
to a 64 bit kernel :)

---8<----
Subject: mm,x86: limit 32 bit kernel to 12GB memory
 
Running 32 bit kernels on very large memory systems is a recipe
for disaster, due to fundamental architectural limits in both
Linux and the hardware. Moreover, all modern hardware with large
memory supports 64 bits.

However, many users continue using 32 bit kernels, and end up
encountering stability and performance problems as a result.

It may be better to save those people the frustration of stability
issues by limiting memory on a 32 bit kernel to 12GB (about the upper
limit that still works right), and printing a friendly reminder that
they really should be using a 64 bit kernel.

Signed-off-by: Rik van Riel <riel@...hat.com>
---
 arch/x86/include/asm/setup.h |  1 +
 arch/x86/mm/init_32.c        | 11 +++++++++++
 2 files changed, 12 insertions(+)

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index b7bf350..79de6bf 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -14,6 +14,7 @@
  */
 #define MAXMEM_PFN	PFN_DOWN(MAXMEM)
 #define MAX_NONPAE_PFN	(1 << 20)
+#define MAX_PAE_PFN	(3 << 20)
 
 #endif /* __i386__ */
 
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 3ac7e31..e35b3f5 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -600,6 +600,12 @@ static void __init lowmem_pfn_init(void)
 
 #define MSG_HIGHMEM_TRIMMED \
 	"Warning: only 4GB will be used. Use a HIGHMEM64G enabled kernel!\n"
+
+#define MSG_HIGHMEM_INSANE \
+	"Warning: 32 bit kernels on large memory systems have problems.\n" \
+	"Limiting memory to 12GB for system stability.\n" \
+	"Use a 64 bit kernel to access all %lu MB of memory.\n"
+
 /*
  * We have more RAM than fits into lowmem - we try to put it into
  * highmem, also taking the highmem=x boot parameter into account:
@@ -634,6 +640,11 @@ static void __init highmem_pfn_init(void)
 		max_pfn = MAX_NONPAE_PFN;
 		printk(KERN_WARNING MSG_HIGHMEM_TRIMMED);
 	}
+#else /* !CONFIG_HIGHMEM64G */
+	if (max_pfn > MAX_PAE_PFN) {
+		printk(KERN_WARNING MSG_HIGHMEM_INSANE, max_pfn>>8);
+		max_pfn = MAX_PFN;
+	}
 #endif /* !CONFIG_HIGHMEM64G */
 #endif /* !CONFIG_HIGHMEM */
 }
--
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/