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  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]
Date:	Mon, 21 Jul 2014 05:35:31 +0000
From:	"Huangpeng (Peter)" <peter.huangpeng@...wei.com>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"mhocko@...e.cz" <mhocko@...e.cz>,
	"liwanp@...ux.vnet.ibm.com" <liwanp@...ux.vnet.ibm.com>,
	"n-horiguchi@...jp.nec.com" <n-horiguchi@...jp.nec.com>,
	"iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
CC:	"Wulizhen (Pss)" <pss.wulizhen@...wei.com>
Subject: [PATCH] mm:bugfix, pfn_valid sometimes return incorrect when memmap parameter specified

In sparse memory mode, I add "memmap = 200M$0x1033800000" into menu.lst,
then I found the information in /proc/iomem is shown as:
.................
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : reserved
    fee00000-fee00fff : pnp 00:08
fff00000-ffffffff : reserved
100000000-10337fffff : System RAM
1033800000-103fffffff : reserved
the return value of function pfn_valid, which checks whether pfn 0x1033800 is valid,
is non-zero.Thus, it will thereafter run the function PageReserved(), which returns 0,
I think the return value of 0 is wrong, as that pfn 0x1033800 is actually reserved.
I probed further, and found that: the section [0x1033000000~0x1033AFFFFFF], including
pfn 0x1033800, is initialized during kernel starting up. However, the page sturctures
corresponding to that section are just partially initialzed,
known as [0x1033000000~(max_pfn -1)](max_pfn = 0x1033800). Which means that, pfn 0x1033800
is valid(as function pfn_valid tells), but its related page structures are not initialized,
which results in the problem shown above: pfn 0x1033800 is of type reserved, but the function
PageReserved shows that it's not.

i think in the funtion of pfn_valid should be add a condition: pfn >= max_pfn.

Signed-off-by: Wulizhen <pss.wulizhen@...wei.com>
---
 include/linux/mmzone.h | 2 +-
 mm/nobootmem.c         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 835aa3d..c54284b 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1199,7 +1199,7 @@ static inline struct mem_section *__pfn_to_section(unsigned long pfn)
 #ifndef CONFIG_HAVE_ARCH_PFN_VALID
 static inline int pfn_valid(unsigned long pfn)
 {
- if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
+ if (pfn >= max_pfn || pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
  return 0;
  return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
 }
diff --git a/mm/nobootmem.c b/mm/nobootmem.c
index 04a9d94..7eb273e 100644
--- a/mm/nobootmem.c
+++ b/mm/nobootmem.c
@@ -31,7 +31,7 @@ EXPORT_SYMBOL(contig_page_data);
 unsigned long max_low_pfn;
 unsigned long min_low_pfn;
 unsigned long max_pfn;
-
+EXPORT_SYMBOL(max_pfn);
 static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align,
  u64 goal, u64 limit)
 {

Powered by blists - more mailing lists