diff options
| author | Andi Kleen <ak@linux.intel.com> | 2008-08-15 18:12:47 +0200 |
|---|---|---|
| committer | Andi Kleen <ak@linux.intel.com> | 2008-08-15 18:18:38 +0200 |
| commit | e213e87785559eaf3107897226817aea9291b06f (patch) | |
| tree | 078999e27fd76b858b2e96f930e828913afe00f3 /arch | |
| parent | b635acec48bcaa9183fcbf4e3955616b0d4119b5 (diff) | |
| download | linux-3.10-e213e87785559eaf3107897226817aea9291b06f.tar.gz linux-3.10-e213e87785559eaf3107897226817aea9291b06f.tar.bz2 linux-3.10-e213e87785559eaf3107897226817aea9291b06f.zip | |
x86: Fix ioremap off by one BUG
Jean Delvare's machine triggered this BUG
acpi_os_map_memory phys ffff0000 size 65535
------------[ cut here ]------------
kernel BUG at arch/x86/mm/pat.c:233!
with ACPI in the backtrace.
Adding some debugging output showed that ACPI calls
acpi_os_map_memory phys ffff0000 size 65535
And ioremap/PAT does this check in 32bit, so addr+size wraps and the BUG
in reserve_memtype() triggers incorrectly.
BUG_ON(start >= end); /* end is exclusive */
But reserve_memtype already uses u64:
int reserve_memtype(u64 start, u64 end,
so the 32bit truncation must happen in the caller. Presumably in ioremap
when it passes this information to reserve_memtype().
This patch does this computation in 64bit.
http://bugzilla.kernel.org/show_bug.cgi?id=11346
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Diffstat (limited to 'arch')
| -rw-r--r-- | arch/x86/mm/ioremap.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 016f335bbee..6ba6f889c79 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -170,7 +170,7 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr, phys_addr &= PAGE_MASK; size = PAGE_ALIGN(last_addr+1) - phys_addr; - retval = reserve_memtype(phys_addr, phys_addr + size, + retval = reserve_memtype(phys_addr, (u64)phys_addr + size, prot_val, &new_prot_val); if (retval) { pr_debug("Warning: reserve_memtype returned %d\n", retval); |