From: ck ck <consul.kautuk@gmail.com>
To: Russell King <rmk@arm.linux.org.uk>,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: yad.naveen@gmail.com, linux-arm-kernel-request@lists.arm.linux.org.uk
Subject: Crashes on ARM platform when sparsemem enabled in linux-2.6.35.13 due to pfn_valid() and pfn_valid_within().
Date: Thu, 28 Jul 2011 14:28:48 +0530 [thread overview]
Message-ID: <CAFPAmTSDrQd53NsaWZfm9GFfUj4fHt9kUGACDkM33=2UxP212w@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3687 bytes --]
Hi,
On my ARM machine, the total kernel memory is not aligned to the section
size SECTION_SIZE_BITS.
I observe kernel crashes in the following 3 scenarios:
i) When we do a "cat /proc/pagetypeinfo": This happens because the
pfn_valid() macro is not able to detect invalid PFNs in the loop in
vmstat.c: pagetypeinfo_showblockcount_print().
ii) When we do "echo xxxx > /proc/vm/sys/min_free_kbytes": This happens
because the pfn_valid() macro is not able to detect invalid PFNs in
page_alloc.c:
setup_zone_migrate_reserve().
iii) When I try to copy a really huge file form one directory to another:
This happens because the CONFIG_HOLES_IN_ZONE config option is not set.
So,
the code in move_freepages() crashes.
I did find one patch somewhat related to this problem at:
https://patchwork.kernel.org/patch/793862/
However, this patch is not suitable for my version of linux-2.6.35.13
because this uses memblock_*() functionality and
CONFIG_HAVE_MEMBLOCK is not enabled for my platform. Also, I am not sure
whether this will solve point iii) above, as pfn_valid_within()
will continue to return 1 back to the caller when it should be calling
pfn_vald() instead.
I created a solution patch for this and would appreciate it if anyone in
these mailing lists could review this patch and tell me whether:
i) There is a better way to do this or,
ii) There is already a more suitable patch for the configuration I am
mentioning above.
Patch:
--- linux-2.6.35.11.p29-FR/arch/arm/Kconfig 2011-07-27 10:27:02.243936001
+0530
+++ linux-2.6.35.11.p29-FR.new/arch/arm/Kconfig 2011-07-27
09:54:00.823935866 +0530
@@ -581,6 +581,16 @@ config OABI_COMPAT
config ARCH_HAS_HOLES_MEMORYMODEL
bool
+config ARCH_HAS_PFN_VALID
+ bool
+ depends on SPARSEMEM
+ default y
+
+config HOLES_IN_ZONE
+ bool
+ depends on SPARSEMEM
+ default y
+
# Discontigmem is deprecated
config ARCH_DISCONTIGMEM_ENABLE
bool
--- linux-2.6.35.9/arch/arm/mm/init.c 2011-06-13 15:18:47.921796999 +0530
+++ linux-2.6.35.9.new/arch/arm/mm/init.c 2011-06-13 11:59:47.236796983
+0530
@@ -350,6 +350,27 @@ static void arm_memory_present(struct me
{
}
#else
+#ifdef CONFIG_ARCH_HAS_PFN_VALID
+int arch_pfn_valid(unsigned long pfn)
+{
+ struct meminfo *mi = &meminfo;
+ unsigned int left = 0, right = mi->nr_banks;
+
+ do {
+ unsigned int mid = (right + left) / 2;
+ struct membank *bank = &mi->bank[mid];
+
+ if (pfn < bank_pfn_start(bank))
+ right = mid;
+ else if (pfn >= bank_pfn_end(bank))
+ left = mid + 1;
+ else
+ return 1;
+ } while (left < right);
+ return 0;
+}
+#endif
+
static void arm_memory_present(struct meminfo *mi, int node)
{
int i;
--- linux-2.6.35.9/include/linux/mmzone.h 2010-11-23 00:31:26.000000000
+0530
+++ linux-2.6.35.9.new/include/linux/mmzone.h 2011-06-13 12:32:37.182796701
+0530
@@ -1062,10 +1062,20 @@ static inline struct mem_section *__pfn_
return __nr_to_section(pfn_to_section_nr(pfn));
}
+#ifdef CONFIG_ARCH_HAS_PFN_VALID
+int arch_pfn_valid(unsigned long) ;
+#endif
+
static inline int pfn_valid(unsigned long pfn)
{
if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
return 0;
+
+#ifdef CONFIG_ARCH_HAS_PFN_VALID
+ if (!arch_pfn_valid(pfn))
+ return 0 ;
+#endif
+
return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
}
@@ -1073,6 +1083,12 @@ static inline int pfn_present(unsigned l
{
if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
return 0;
+
+#ifdef CONFIG_ARCH_HAS_PFN_VALID
+ if (!arch_pfn_valid(pfn))
+ return 0 ;
+#endif
+
return present_section(__nr_to_section(pfn_to_section_nr(pfn)));
}
Thanks,
Kautuk.
[-- Attachment #2: Type: text/html, Size: 4611 bytes --]
reply other threads:[~2011-07-28 8:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='CAFPAmTSDrQd53NsaWZfm9GFfUj4fHt9kUGACDkM33=2UxP212w@mail.gmail.com' \
--to=consul.kautuk@gmail.com \
--cc=linux-arm-kernel-request@lists.arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rmk@arm.linux.org.uk \
--cc=yad.naveen@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox