linux-kernel - [tip:x86/urgent] x86/kexec/64: Use gbpages for identity mappings if available

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: <tip-8638100c52bb7782462b14aad102a4aaf0c7094c@git.kernel.org>
Date:   Mon, 8 May 2017 01:01:44 -0700
From:   tip-bot for Xunlei Pang <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     jpoimboe@...hat.com, torvalds@...ux-foundation.org,
        mingo@...nel.org, bp@...en8.de, yinghai@...nel.org,
        dyoung@...hat.com, luto@...nel.org, linux-kernel@...r.kernel.org,
        brgerst@...il.com, ebiederm@...ssion.com, xlpang@...hat.com,
        peterz@...radead.org, tglx@...utronix.de, dvlasenk@...hat.com,
        hpa@...or.com
Subject: [tip:x86/urgent] x86/kexec/64: Use gbpages for identity mappings if
 available

Commit-ID:  8638100c52bb7782462b14aad102a4aaf0c7094c
Gitweb:     http://git.kernel.org/tip/8638100c52bb7782462b14aad102a4aaf0c7094c
Author:     Xunlei Pang <xlpang@...hat.com>
AuthorDate: Thu, 4 May 2017 09:42:51 +0800
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Mon, 8 May 2017 08:28:44 +0200

x86/kexec/64: Use gbpages for identity mappings if available

Kexec sets up all identity mappings before booting into the new
kernel, and this will cause extra memory consumption for paging
structures which is quite considerable on modern machines with
huge memory sizes.

E.g. on a 32TB machine that is kdumping, it could waste around
128MB (around 4MB/TB) from the reserved memory after kexec sets
all the identity mappings using the current 2MB page.

Add to that the memory needed for the loaded kdump kernel, initramfs,
etc., and it causes a kexec syscall -NOMEM failure.

As a result, we had to enlarge reserved memory via "crashkernel=X"
to work around this problem.

This causes some trouble for distributions that use policies
to evaluate the proper "crashkernel=X" value for users.

So enable gbpages for kexec mappings.

Signed-off-by: Xunlei Pang <xlpang@...hat.com>
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Borislav Petkov <bp@...en8.de>
Cc: Brian Gerst <brgerst@...il.com>
Cc: Dave Young <dyoung@...hat.com>
Cc: Denys Vlasenko <dvlasenk@...hat.com>
Cc: Eric Biederman <ebiederm@...ssion.com>
Cc: H. Peter Anvin <hpa@...or.com>
Cc: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Yinghai Lu <yinghai@...nel.org>
Cc: akpm@...ux-foundation.org
Cc: kexec@...ts.infradead.org
Link: http://lkml.kernel.org/r/1493862171-8799-2-git-send-email-xlpang@redhat.com
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 arch/x86/kernel/machine_kexec_64.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 1d4f2b0..c25d277 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
 
 	level4p = (pgd_t *)__va(start_pgtable);
 	clear_page(level4p);
+
+	if (direct_gbpages)
+		info.direct_gbpages = true;
+
 	for (i = 0; i < nr_pfn_mapped; i++) {
 		mstart = pfn_mapped[i].start << PAGE_SHIFT;
 		mend   = pfn_mapped[i].end << PAGE_SHIFT;