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]
Message-ID: <20130501224604.21ebc42a@annuminas.surriel.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ