From: Minchan Kim <minchan.kim@gmail.com>
To: linux@arm.linux.org.uk, Yinghai Lu <yinghai@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
Shaohua Li <shaohua.li@intel.com>,
Yakui Zhao <yakui.zhao@intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
arm-kernel@lists.infradead.org, kgene.kim@samsung.com,
Mel Gorman <mel@csn.ul.ie>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: [RFC] Tight check of pfn_valid on sparsemem
Date: Tue, 13 Jul 2010 00:53:48 +0900 [thread overview]
Message-ID: <20100712155348.GA2815@barrios-desktop> (raw)
Kukjin, Could you test below patch?
I don't have any sparsemem system. Sorry.
-- CUT DOWN HERE --
Kukjin reported oops happen while he change min_free_kbytes
http://www.spinics.net/lists/arm-kernel/msg92894.html
It happen by memory map on sparsemem.
The system has a memory map following as.
section 0 section 1 section 2
0x20000000-0x25000000, 0x40000000-0x50000000, 0x50000000-0x58000000
SECTION_SIZE_BITS 28(256M)
It means section 0 is an incompletely filled section.
Nontheless, current pfn_valid of sparsemem checks pfn loosely.
It checks only mem_section's validation.
So in above case, pfn on 0x25000000 can pass pfn_valid's validation check.
It's not what we want.
The Following patch adds check valid pfn range check on pfn_valid of sparsemem.
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Reported-by: Kukjin Kim <kgene.kim@samsung.com>
P.S)
It is just RFC. If we agree with this, I will make the patch on mmotm.
--
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index b4d109e..6c2147a 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -979,6 +979,8 @@ struct mem_section {
struct page_cgroup *page_cgroup;
unsigned long pad;
#endif
+ unsigned long start_pfn;
+ unsigned long end_pfn;
};
#ifdef CONFIG_SPARSEMEM_EXTREME
@@ -1039,6 +1041,12 @@ static inline int valid_section(struct mem_section *section)
return (section && (section->section_mem_map & SECTION_HAS_MEM_MAP));
}
+static inline int valid_section_pfn(struct mem_section *section, unsigned long pfn)
+{
+ return ((section && (section->section_mem_map & SECTION_HAS_MEM_MAP)) &&
+ (section->start_pfn <= pfn && pfn < section->end_pfn));
+}
+
static inline int valid_section_nr(unsigned long nr)
{
return valid_section(__nr_to_section(nr));
@@ -1053,7 +1061,7 @@ static inline int pfn_valid(unsigned long pfn)
{
if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
return 0;
- return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
+ return valid_section_pfn(__nr_to_section(pfn_to_section_nr(pfn)), pfn);
}
diff --git a/mm/sparse.c b/mm/sparse.c
index 95ac219..bde9090 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -195,6 +195,8 @@ void __init memory_present(int nid, unsigned long start, unsigned long end)
if (!ms->section_mem_map)
ms->section_mem_map = sparse_encode_early_nid(nid) |
SECTION_MARKED_PRESENT;
+ ms->start_pfn = start;
+ ms->end_pfn = end;
}
}
--
Kind regards,
Minchan Kim
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan.kim@gmail.com>
To: linux@arm.linux.org.uk, Yinghai Lu <yinghai@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
Shaohua Li <shaohua.li@intel.com>,
Yakui Zhao <yakui.zhao@intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
arm-kernel@lists.infradead.org, kgene.kim@samsung.com,
Mel Gorman <mel@csn.ul.ie>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: [RFC] Tight check of pfn_valid on sparsemem
Date: Tue, 13 Jul 2010 00:53:48 +0900 [thread overview]
Message-ID: <20100712155348.GA2815@barrios-desktop> (raw)
Kukjin, Could you test below patch?
I don't have any sparsemem system. Sorry.
-- CUT DOWN HERE --
Kukjin reported oops happen while he change min_free_kbytes
http://www.spinics.net/lists/arm-kernel/msg92894.html
It happen by memory map on sparsemem.
The system has a memory map following as.
section 0 section 1 section 2
0x20000000-0x25000000, 0x40000000-0x50000000, 0x50000000-0x58000000
SECTION_SIZE_BITS 28(256M)
It means section 0 is an incompletely filled section.
Nontheless, current pfn_valid of sparsemem checks pfn loosely.
It checks only mem_section's validation.
So in above case, pfn on 0x25000000 can pass pfn_valid's validation check.
It's not what we want.
The Following patch adds check valid pfn range check on pfn_valid of sparsemem.
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Reported-by: Kukjin Kim <kgene.kim@samsung.com>
P.S)
It is just RFC. If we agree with this, I will make the patch on mmotm.
--
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index b4d109e..6c2147a 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -979,6 +979,8 @@ struct mem_section {
struct page_cgroup *page_cgroup;
unsigned long pad;
#endif
+ unsigned long start_pfn;
+ unsigned long end_pfn;
};
#ifdef CONFIG_SPARSEMEM_EXTREME
@@ -1039,6 +1041,12 @@ static inline int valid_section(struct mem_section *section)
return (section && (section->section_mem_map & SECTION_HAS_MEM_MAP));
}
+static inline int valid_section_pfn(struct mem_section *section, unsigned long pfn)
+{
+ return ((section && (section->section_mem_map & SECTION_HAS_MEM_MAP)) &&
+ (section->start_pfn <= pfn && pfn < section->end_pfn));
+}
+
static inline int valid_section_nr(unsigned long nr)
{
return valid_section(__nr_to_section(nr));
@@ -1053,7 +1061,7 @@ static inline int pfn_valid(unsigned long pfn)
{
if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
return 0;
- return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
+ return valid_section_pfn(__nr_to_section(pfn_to_section_nr(pfn)), pfn);
}
diff --git a/mm/sparse.c b/mm/sparse.c
index 95ac219..bde9090 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -195,6 +195,8 @@ void __init memory_present(int nid, unsigned long start, unsigned long end)
if (!ms->section_mem_map)
ms->section_mem_map = sparse_encode_early_nid(nid) |
SECTION_MARKED_PRESENT;
+ ms->start_pfn = start;
+ ms->end_pfn = end;
}
}
--
Kind regards,
Minchan Kim
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2010-07-12 15:53 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-12 15:53 Minchan Kim [this message]
2010-07-12 15:53 ` [RFC] Tight check of pfn_valid on sparsemem Minchan Kim
2010-07-12 23:59 ` Kukjin Kim
2010-07-12 23:59 ` Kukjin Kim
2010-07-13 3:19 ` KAMEZAWA Hiroyuki
2010-07-13 3:19 ` KAMEZAWA Hiroyuki
2010-07-13 4:11 ` Minchan Kim
2010-07-13 4:11 ` Minchan Kim
2010-07-13 4:23 ` KAMEZAWA Hiroyuki
2010-07-13 4:23 ` KAMEZAWA Hiroyuki
2010-07-13 6:04 ` Minchan Kim
2010-07-13 6:04 ` Minchan Kim
2010-07-13 6:40 ` KAMEZAWA Hiroyuki
2010-07-13 6:40 ` KAMEZAWA Hiroyuki
2010-07-13 8:06 ` Minchan Kim
2010-07-13 8:06 ` Minchan Kim
2010-07-13 8:03 ` KAMEZAWA Hiroyuki
2010-07-13 8:03 ` KAMEZAWA Hiroyuki
2010-07-13 7:20 ` Russell King - ARM Linux
2010-07-13 7:20 ` Russell King - ARM Linux
2010-07-13 7:34 ` KAMEZAWA Hiroyuki
2010-07-13 7:34 ` KAMEZAWA Hiroyuki
2010-07-13 7:58 ` KAMEZAWA Hiroyuki
2010-07-13 7:58 ` KAMEZAWA Hiroyuki
2010-07-13 8:02 ` KAMEZAWA Hiroyuki
2010-07-13 8:02 ` KAMEZAWA Hiroyuki
2010-07-13 18:39 ` Russell King - ARM Linux
2010-07-13 18:39 ` Russell King - ARM Linux
2010-07-13 20:46 ` Dave Hansen
2010-07-13 20:46 ` Dave Hansen
2010-07-13 9:30 ` Johannes Weiner
2010-07-13 9:30 ` Johannes Weiner
2010-07-13 15:43 ` Minchan Kim
2010-07-13 15:43 ` Minchan Kim
2010-07-13 16:35 ` Dave Hansen
2010-07-13 16:35 ` Dave Hansen
2010-07-13 16:44 ` Minchan Kim
2010-07-13 16:44 ` Minchan Kim
2010-07-14 0:23 ` KAMEZAWA Hiroyuki
2010-07-14 0:23 ` KAMEZAWA Hiroyuki
2010-07-14 6:44 ` Minchan Kim
2010-07-14 6:44 ` Minchan Kim
2010-07-14 7:10 ` KAMEZAWA Hiroyuki
2010-07-14 7:10 ` KAMEZAWA Hiroyuki
2010-07-14 7:35 ` Minchan Kim
2010-07-14 7:35 ` Minchan Kim
2010-07-14 7:39 ` KAMEZAWA Hiroyuki
2010-07-14 7:39 ` KAMEZAWA Hiroyuki
2010-07-14 7:50 ` Kukjin Kim
2010-07-14 7:50 ` Kukjin Kim
2010-07-14 8:09 ` KAMEZAWA Hiroyuki
2010-07-14 8:09 ` KAMEZAWA Hiroyuki
2010-07-13 9:37 ` Mel Gorman
2010-07-13 9:37 ` Mel Gorman
2010-07-13 9:46 ` Russell King - ARM Linux
2010-07-13 9:46 ` Russell King - ARM Linux
2010-07-13 10:00 ` Mel Gorman
2010-07-13 10:00 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100712155348.GA2815@barrios-desktop \
--to=minchan.kim@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arm-kernel@lists.infradead.org \
--cc=hpa@zytor.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kgene.kim@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=mel@csn.ul.ie \
--cc=shaohua.li@intel.com \
--cc=yakui.zhao@intel.com \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.