linux-kernel - [tip:x86/urgent] x86/mm/ptdump: Fix soft lockup in page table walker

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-146fbb766934dc003fcbf755b519acef683576bf@git.kernel.org>
Date:   Fri, 10 Feb 2017 02:07:05 -0800
From:   tip-bot for Andrey Ryabinin <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     mingo@...nel.org, hpa@...or.com, paulmck@...ux.vnet.ibm.com,
        tobias.regnery@...il.com, glider@...gle.com,
        aryabinin@...tuozzo.com, tglx@...utronix.de, dvyukov@...gle.com,
        linux-kernel@...r.kernel.org
Subject: [tip:x86/urgent] x86/mm/ptdump: Fix soft lockup in page table
 walker

Commit-ID:  146fbb766934dc003fcbf755b519acef683576bf
Gitweb:     http://git.kernel.org/tip/146fbb766934dc003fcbf755b519acef683576bf
Author:     Andrey Ryabinin <aryabinin@...tuozzo.com>
AuthorDate: Fri, 10 Feb 2017 12:54:05 +0300
Committer:  Thomas Gleixner <tglx@...utronix.de>
CommitDate: Fri, 10 Feb 2017 11:00:23 +0100

x86/mm/ptdump: Fix soft lockup in page table walker

CONFIG_KASAN=y needs a lot of virtual memory mapped for its shadow.
In that case ptdump_walk_pgd_level_core() takes a lot of time to
walk across all page tables and doing this without
a rescheduling causes soft lockups:

 NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [swapper/0:1]
 ...
 Call Trace:
  ptdump_walk_pgd_level_core+0x40c/0x550
  ptdump_walk_pgd_level_checkwx+0x17/0x20
  mark_rodata_ro+0x13b/0x150
  kernel_init+0x2f/0x120
  ret_from_fork+0x2c/0x40

I guess that this issue might arise even without KASAN on huge machines
with several terabytes of RAM.

Stick cond_resched() in pgd loop to fix this.

Reported-by: Tobias Regnery <tobias.regnery@...il.com>
Signed-off-by: Andrey Ryabinin <aryabinin@...tuozzo.com>
Cc: kasan-dev@...glegroups.com
Cc: Alexander Potapenko <glider@...gle.com>
Cc: "Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: Dmitry Vyukov <dvyukov@...gle.com>
Cc: stable@...r.kernel.org
Link: http://lkml.kernel.org/r/20170210095405.31802-1-aryabinin@virtuozzo.com
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>

---
 arch/x86/mm/dump_pagetables.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index ea9c49a..8aa6bea 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -15,6 +15,7 @@
 #include <linux/debugfs.h>
 #include <linux/mm.h>
 #include <linux/init.h>
+#include <linux/sched.h>
 #include <linux/seq_file.h>

 #include <asm/pgtable.h>
@@ -406,6 +407,7 @@ static void ptdump_walk_pgd_level_core(struct seq_file *m, pgd_t *pgd,
 		} else
 			note_page(m, &st, __pgprot(0), 1);

+		cond_resched();
 		start++;
 	}