linux-kernel - Re: 2.6.33-git6 boot failure[x86_64] (WARN: at arch/x86/mm/ioremap.c:111)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100301135551.GA9998@localhost>
Date:	Mon, 1 Mar 2010 21:55:51 +0800
From:	Wu Fengguang <fengguang.wu@...el.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Xiaotian Feng <xtfeng@...il.com>, Sachin Sant <sachinp@...ibm.com>,
	Yinghai Lu <yinghai@...nel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: 2.6.33-git6 boot failure[x86_64] (WARN: at
	arch/x86/mm/ioremap.c:111)

On Mon, Mar 01, 2010 at 06:42:59PM +0800, Thomas Gleixner wrote:
> On Mon, 1 Mar 2010, Xiaotian Feng wrote:
> > On Mon, Mar 1, 2010 at 4:28 PM, Sachin Sant <sachinp@...ibm.com> wrote:
> > > Xiaotian Feng wrote:
> > >> On Mon, Mar 1, 2010 at 12:34 PM, Sachin Sant <sachinp@...ibm.com> wrote:
> >
> > >>> WARNING: at arch/x86/mm/ioremap.c:111 __ioremap_caller+0x169/0x2f1()
> > >>> Hardware name: BladeCenter LS21 -[79716AA]-
> > >>> Modules linked in:
> > >>> Pid: 0, comm: swapper Not tainted 2.6.33-git6-autotest #1
> > >>> Call Trace:
> > >>> [<ffffffff81047cff>] ? __ioremap_caller+0x169/0x2f1
> > >>> [<ffffffff81063b7d>] warn_slowpath_common+0x77/0xa4
> > >>> [<ffffffff81063bb9>] warn_slowpath_null+0xf/0x11
> > >>> [<ffffffff81047cff>] __ioremap_caller+0x169/0x2f1
> > >>> [<ffffffff813747a3>] ? acpi_os_map_memory+0x12/0x1b
> > >>> [<ffffffff81047f10>] ioremap_nocache+0x12/0x14
> > >>> [<ffffffff813747a3>] acpi_os_map_memory+0x12/0x1b
> > >>> [<ffffffff81282fa0>] acpi_tb_verify_table+0x29/0x5b
> > >>> [<ffffffff812827f0>] acpi_load_tables+0x39/0x15a
> > >>> [<ffffffff8191c8f8>] acpi_early_init+0x60/0xf5
> > >>> [<ffffffff818f2cad>] start_kernel+0x397/0x3a7
> > >>> [<ffffffff818f2295>] x86_64_start_reservations+0xa5/0xa9
> > >>> [<ffffffff818f237a>] x86_64_start_kernel+0xe1/0xe8
> > >>> ---[ end trace 4eaa2a86a8e2da22 ]---
> > >>> ioremap reserve_memtype failed -22
> 
> The return code is -EINVAL, so it failed in the is_ram check, which is
> not too surprising
> 
> > BIOS-provided physical RAM map:
> >  BIOS-e820: 0000000000000000 - 000000000009c000 (usable)
> >  BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved)
> >  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> >  BIOS-e820: 0000000000100000 - 00000000cffa3900 (usable)
> >  BIOS-e820: 00000000cffa3900 - 00000000cffa7400 (ACPI data)
> 
> The ACPI data is not starting on a page boundary and neither does the
> usable RAM area end on a page boundary. Very useful !
> 
> > ACPI: DSDT 00000000cffa3900 036CE (v01 IBM    SERLEWIS 00001000 INTL 20060912)
> 
> ACPI is trying to map DSDT at cffa3900, which results in a check
> vs. cffa3000 which is the relevant page boundary. The generic is_ram
> check correctly identifies that as RAM because it's in the usable
> resource area. The old e820 based is_ram check does not take
> overlapping resource areas into account. That's why it works.
> 
> We probably need to sanitize the E820 map befor throwing it at the
> resource manager.

Ah walk_system_ram_range() is actually doing almost the same alignment
check as the removed x86 page_is_ram(), except that it calls func()
with len=0.  This happens when page_is_ram(cffa3000) is called.

walk_system_ram_range():
               pfn = (unsigned long)(res.start >> PAGE_SHIFT);                                                                      
               len = (unsigned long)((res.end + 1 - res.start) >> PAGE_SHIFT);                                                      
               ret = (*func)(pfn, len, arg);                                                                                        

The following patch should fix the problem.

Thanks,
Fengguang
---
resource: fix generic page_is_ram() for partial RAM pages

The System RAM walk shall skip partial RAM pages and avoid calling
func() on them. So that page_is_ram() return 0 for a partial RAM page.

In particular, it shall not call func() with len=0.
This fixes a boot time bug reported by Sachin and root caused by Thomas:

> >>> WARNING: at arch/x86/mm/ioremap.c:111 __ioremap_caller+0x169/0x2f1()
> >>> Hardware name: BladeCenter LS21 -[79716AA]-
> >>> Modules linked in:
> >>> Pid: 0, comm: swapper Not tainted 2.6.33-git6-autotest #1
> >>> Call Trace:
> >>> [<ffffffff81047cff>] ? __ioremap_caller+0x169/0x2f1
> >>> [<ffffffff81063b7d>] warn_slowpath_common+0x77/0xa4
> >>> [<ffffffff81063bb9>] warn_slowpath_null+0xf/0x11
> >>> [<ffffffff81047cff>] __ioremap_caller+0x169/0x2f1
> >>> [<ffffffff813747a3>] ? acpi_os_map_memory+0x12/0x1b
> >>> [<ffffffff81047f10>] ioremap_nocache+0x12/0x14
> >>> [<ffffffff813747a3>] acpi_os_map_memory+0x12/0x1b
> >>> [<ffffffff81282fa0>] acpi_tb_verify_table+0x29/0x5b
> >>> [<ffffffff812827f0>] acpi_load_tables+0x39/0x15a
> >>> [<ffffffff8191c8f8>] acpi_early_init+0x60/0xf5
> >>> [<ffffffff818f2cad>] start_kernel+0x397/0x3a7
> >>> [<ffffffff818f2295>] x86_64_start_reservations+0xa5/0xa9
> >>> [<ffffffff818f237a>] x86_64_start_kernel+0xe1/0xe8
> >>> ---[ end trace 4eaa2a86a8e2da22 ]---
> >>> ioremap reserve_memtype failed -22

The return code is -EINVAL, so it failed in the is_ram check, which is
not too surprising

> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 000000000009c000 (usable)
>  BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved)
>  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
>  BIOS-e820: 0000000000100000 - 00000000cffa3900 (usable)
>  BIOS-e820: 00000000cffa3900 - 00000000cffa7400 (ACPI data)

The ACPI data is not starting on a page boundary and neither does the
usable RAM area end on a page boundary. Very useful !

> ACPI: DSDT 00000000cffa3900 036CE (v01 IBM    SERLEWIS 00001000 INTL 20060912)

ACPI is trying to map DSDT at cffa3900, which results in a check
vs. cffa3000 which is the relevant page boundary. The generic is_ram
check correctly identifies that as RAM because it's in the usable
resource area. The old e820 based is_ram check does not take
overlapping resource areas into account. That's why it works.


CC: Sachin Sant <sachinp@...ibm.com>
CC: Thomas Gleixner <tglx@...utronix.de>
CC: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Signed-off-by: Wu Fengguang <fengguang.wu@...el.com>
---
 kernel/resource.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

--- linux.orig/kernel/resource.c	2010-03-01 21:16:04.000000000 +0800
+++ linux/kernel/resource.c	2010-03-01 21:33:32.000000000 +0800
@@ -304,7 +304,7 @@ int walk_system_ram_range(unsigned long 
 		void *arg, int (*func)(unsigned long, unsigned long, void *))
 {
 	struct resource res;
-	unsigned long pfn, len;
+	unsigned long pfn, end_pfn;
 	u64 orig_end;
 	int ret = -1;
 
@@ -314,9 +314,10 @@ int walk_system_ram_range(unsigned long 
 	orig_end = res.end;
 	while ((res.start < res.end) &&
 		(find_next_system_ram(&res, "System RAM") >= 0)) {
-		pfn = (unsigned long)(res.start >> PAGE_SHIFT);
-		len = (unsigned long)((res.end + 1 - res.start) >> PAGE_SHIFT);
-		ret = (*func)(pfn, len, arg);
+		pfn = (res.start + PAGE_SIZE - 1) >> PAGE_SHIFT;
+		end_pfn = (res.end + 1) >> PAGE_SHIFT;
+		if (end_pfn > pfn)
+		    ret = (*func)(pfn, end_pfn - pfn, arg);
 		if (ret)
 			break;
 		res.start = res.end + 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/