diff options
author | Dave Hansen <dave@linux.vnet.ibm.com> | 2013-01-22 13:24:30 -0800 |
---|---|---|
committer | H. Peter Anvin <hpa@linux.intel.com> | 2013-01-25 16:33:22 -0800 |
commit | a25b9316841c5afa226f8f70a457861b35276a92 (patch) | |
tree | e1fb6722bcb783329de3c09d7a9df1a6b0f25d58 /arch/x86/include | |
parent | 7b5c4a65cc27f017c170b025f8d6d75dabb11c6f (diff) | |
download | op-kernel-dev-a25b9316841c5afa226f8f70a457861b35276a92.zip op-kernel-dev-a25b9316841c5afa226f8f70a457861b35276a92.tar.gz |
x86, mm: Make DEBUG_VIRTUAL work earlier in boot
The KVM code has some repeated bugs in it around use of __pa() on
per-cpu data. Those data are not in an area on which using
__pa() is valid. However, they are also called early enough in
boot that __vmalloc_start_set is not set, and thus the
CONFIG_DEBUG_VIRTUAL debugging does not catch them.
This adds a check to also verify __pa() calls against max_low_pfn,
which we can use earler in boot than is_vmalloc_addr(). However,
if we are super-early in boot, max_low_pfn=0 and this will trip
on every call, so also make sure that max_low_pfn is set before
we try to use it.
With this patch applied, CONFIG_DEBUG_VIRTUAL will actually
catch the bug I was chasing (and fix later in this series).
I'd love to find a generic way so that any __pa() call on percpu
areas could do a BUG_ON(), but there don't appear to be any nice
and easy ways to check if an address is a percpu one. Anybody
have ideas on a way to do this?
Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20130122212430.F46F8159@kernel.stglabs.ibm.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Diffstat (limited to 'arch/x86/include')
0 files changed, 0 insertions, 0 deletions