linux-kernel - [PATCH] crash_dump: arm: crash dump kernel should use strict pfn

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

Message-ID: <1400138070-24046-1-git-send-email-wangnan0@huawei.com>
Date:	Thu, 15 May 2014 15:14:30 +0800
From:	Wang Nan <wangnan0@...wei.com>
To:	Russell King <linux@....linux.org.uk>,
	Will Deacon <will.deacon@....com>,
	Simon Horman <horms@...ge.net.au>,
	Mika Westerberg <ext-mika.1.westerberg@...ia.com>
CC:	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, Wang Nan <wangnan0@...wei.com>,
	Geng Hui <hui.geng@...wei.com>
Subject: [PATCH] crash_dump: arm: crash dump kernel should use strict pfn_valid

This patch makes crash dump kernel use arch pfn_valid defined in
arch/arm/mm/init.c instead of the one in include/linux/mmzone.h.
The goal of this patch is to remove some limitation when kexec loading
crash kernel while SPARSEMEM is enabled.

Before this patch, if second kernel selects both CRASH_DUMP and
SPARSEMEM, the second kernel will recongnize memorys at the same section
with itself as valid memory, and prevents ioremap (see arm ioremap code,
arm doesn't allow valid memory to be ioremapped again). Which introduces
some limitations on positioning the crash kernel. For example:

  For a platform with SECTION_SIZE_BITS == 28 (256MiB) and
  crashkernel=128M@...8000000 in kernel cmdline, the second
  kernel is loaded at 0x28000000. Kexec puts elfcorehdr at
  0x2ff00000, and passes 'elfcorehdr=0x2ff00000 mem=130048K' to
  second kernel. When second kernel start, it tries to use
  ioremap to retrive its elfcorehrd. In this case, elfcodehdr is at the
  same section of the second kernel, pfn_valid will recongnize
  the page as valid, so ioremap will refuse to map it.

Even if we put crash kernel at the boundary of two sections (such as
129MB@...x28000000 in the above situation), 0x20000000-0x28000000 used
by old kernel is still unable to retrived by crash kernel because they
are at the same section.

This patch makes crash dump kernel use strict (and slow) version of
pfn_valid(), which makes crash kernel recongnize memory correctly.

Signed-off-by: Wang Nan <wangnan0@...wei.com>
Cc: Geng Hui <hui.geng@...wei.com>
Cc: Mika Westerberg <ext-mika.1.westerberg@...ia.com>
Cc: Simon Horman <horms@...ge.net.au>
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index db3c541..795b1d4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1800,7 +1800,7 @@ config ARCH_SELECT_MEMORY_MODEL
 	def_bool ARCH_SPARSEMEM_ENABLE

 config HAVE_ARCH_PFN_VALID
-	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
+	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM || CRASH_DUMP

 config HIGHMEM
 	bool "High Memory Support"
-- 
1.8.4

--
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/