From: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
To: linux-mm@kvack.org
Cc: Mel Gorman <mgorman@suse.de>
Subject: [BUG] 3.2.2 crash in isolate_migratepages
Date: Fri, 27 Jan 2012 13:43:07 -0800 [thread overview]
Message-ID: <4F231A6B.1050607@oracle.com> (raw)
3.2.2 panics on a 16GB i686 blade:
BUG: unable to handle kernel paging request at 01c00008
IP: [<c0522399>] isolate_migratepages+0x119/0x390
*pdpt = 000000002f7ce001 *pde = 0000000000000000
The crash happens on this line in mm/compaction.c::isolate_migratepages:
328 page = pfn_to_page(low_pfn);
This macro finds the struct page pointer for a given pfn. These struct
page pointers are stored in sections of 131072 pages if
CONFIG_SPARSEMEM=y. If an entire section has no memory pages, the page
structs are not allocated for this section. On this particular machine,
there is no RAM mapped from 2GB - 4GB:
# dmesg|grep usable
BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
BIOS-e820: 0000000000100000 - 000000007fe4e000 (usable)
BIOS-e820: 000000007fe56000 - 000000007fe57000 (usable)
BIOS-e820: 0000000100000000 - 000000047ffff000 (usable)
So there are no page structs for the sections between 2GB and 4GB.
I believe this check was intended to catch page numbers that point to holes:
323 if (!pfn_valid_within(low_pfn))
324 continue;
But pfn_valid_within is defined to (1) on all archs except ARM and ia64
as far as I can tell. So this check always passes (it's in fact
optimized out), and pfn_to_page ends up dereferencing an invalid address
due to a null pointer in the mem_section structure.
Other compaction code checks for pfn_valid(pfn), which actually checks
for the null pointer in the mem_section structure. It is not clear to
me why isolate_migratepages uses pfn_valid_within(). Changing it to
pfn_valid() prevents the crash. It looks like the correct solution to
me, but I'm not familiar with this code.
I also tried this on a 64-bit machine with a 1GB gap at 3GB, but the
address calculated from (struct page *)0 + pfn is a valid readable
memory location, so it doesn't panic. Not sure what other bad things
happen later though.
Any comments, questions, other data you'd like to see?
Thanks,
Herbert.
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2012-01-27 21:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-27 21:43 Herbert van den Bergh [this message]
2012-01-30 9:09 ` [BUG] 3.2.2 crash in isolate_migratepages Mel Gorman
2012-01-30 18:16 ` Herbert van den Bergh
2012-01-30 18:28 ` Michal Nazarewicz
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=4F231A6B.1050607@oracle.com \
--to=herbert.van.den.bergh@oracle.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
/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.