linux-kernel - Re: [PATCH] x86/mm: Limit 2/4M size calculation to x86

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

Message-ID: <5049D698.1020405@canonical.com>
Date:	Fri, 07 Sep 2012 13:12:24 +0200
From:	Stefan Bader <stefan.bader@...onical.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Avi Kivity <avi@...hat.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	Ingo Molnar <mingo@...e.hu>, Yinghai Lu <yinghai@...nel.org>,
	Tejun Heo <tj@...nel.org>,
	Konrad Rezeszutek Wilk <konrad.wilk@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>
Subject: Re: [PATCH] x86/mm: Limit 2/4M size calculation to x86_32

On 31.08.2012 18:41, H. Peter Anvin wrote:
> I'm not saying we shouldn't patch the regression, but this house of cards
> *needs* to be replaced with something robust and correct by construction.

Could that patch then get applied? Though I got some feedback, that the
description might be not really well written. So I am attaching a version that
tries to do better. The code change itself is the same.

-Stefan

---

From 737a5ebdd7ac1f4106cb0b0c53cc8f73b6ff1aca Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@...onical.com>
Date: Fri, 13 Jul 2012 15:16:33 +0200
Subject: [PATCH] x86/mm: Limit extra padding calculation to x86_32

Starting with kernel v3.5 kexec based crash dumping was observed to fail
(without any apparent message) on x86_64 machines.  This was traced to
a lack of memory triggered by a substantial increase (several megabyes)
in the size of the initial page tables.

 After regression (on a VM with 2GB of memory):
 kernel direct mapping tables up to 0x7fffcfff @ [mem 0x1fbfd000-0x1fffffff]
 size = 4206591 bytes

 With this patch applied:
 kernel direct mapping tables up to 0x7fffcfff @ [mem 0x1fffc000-0x1fffffff]
 size = 16383 bytes

A bisection lead to the commit below:

commit 722bc6b (x86/mm: Fix the size calculation of mapping tables)

This change modified the extra space calculation to take into account
that the first 2/4M range of memory would be mapped as 4K pages as
suggested in chapter 11.11.9 of the Intel software developer's manual.

However this is currently only true for x86_32 (the reasons behind that
are unclear but apparently the whole page table setup needs to be re-
visited as it turns out to be very easy to break and has flaws in its
current form).

Until the logic can be revisited and combined, pair up the extra space
calculation with the logic which creates the extra mappings.

Signed-off-by: Stefan Bader <stefan.bader@...onical.com>
Cc: stable@...r.kernel.org # v3.5+
Cc: WANG Cong <xiyou.wangcong@...il.com>
Cc: Yinghai Lu <yinghai@...nel.org>
Cc: Tejun Heo <tj@...nel.org>
---
 arch/x86/mm/init.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index bc4e9d8..636bbfd 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -60,10 +60,11 @@ static void __init find_early_table_space(struct map_range
*mr, unsigned long en
 		extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT);
 #ifdef CONFIG_X86_32
 		extra += PMD_SIZE;
-#endif
+
 		/* The first 2/4M doesn't use large pages. */
 		if (mr->start < PMD_SIZE)
 			extra += mr->end - mr->start;
+#endif

 		ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
 	} else
-- 
1.7.9.5

View attachment "0001-x86-mm-Limit-2-4M-size-calculation-to-x86_32.patch" of type "text/x-diff" (2247 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (898 bytes)