linux-kernel - Re: kexec + ACPI in 2.6.19 (was: Re: kexec + USB storage in 2.6.19)

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Jan 2007 10:33:34 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Dan Aloni <da-x@...atomic.org>
Cc:	Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: Re: kexec + ACPI in 2.6.19 (was: Re: kexec + USB storage in 2.6.19)

Dan Aloni <da-x@...atomic.org> writes:

> On Fri, Jan 12, 2007 at 06:43:40PM +0200, Dan Aloni wrote:
>> On Fri, Jan 12, 2007 at 06:28:00PM +0200, Dan Aloni wrote:
>> > On Fri, Jan 12, 2007 at 06:02:43PM +0200, Dan Aloni wrote:
>> > > On Fri, Jan 12, 2007 at 08:26:03AM -0700, Eric W. Biederman wrote:
>> > > > Dan Aloni <da-x@...atomic.org> writes:
>> > > > 
>> > > > > I'm attaching the full logs.
>> > > > 
>> > > > Thanks.
>> > > > 
>> > > > > [ 8656.272980] ACPI Error (tbxfroot-0512): Could not map memory at
> 0000040E for length 2 [20060707]
>> > > > 
>> > > > Ok. This looks like the first sign of trouble.
>> > > > Normally I would suspect a memory map issue but your e820 memory map
> looks fine,
>> > > > although a little different between the two kernels.
>> > > > 
>> > > > Is this enough of a hint for you to dig more deeply?
>> > > 
>> > > Reverting just the ACPI code (everything under drivers/acpi/*) 
>> > > back to the version of 2.6.18.3 doesn't fix the problem, so it 
>> > > must be something else.
>> > 
>> > Just occured to me that I didn't revert the relevant code under 
>> > arch/x86_64 so it might still be related somehow..
>> 
>> After adding a few prints inside __ioremap() it appears the function
>> exits for phys_addr==0x40e because (!PageReserved(page)).
>> 
>> Isn't page 0 supposed to be reserved? I clearly see that it is
>> being reserved under setup_arch(). 
>> 
>> Odd, I must say...
>
> In __ioremap() I added this under if(!PageReserved(page)) {...}:
>
> 		if (phys_addr == 0x40e) {
> 			printk("PAGE %p (pfn=%ld): flags=%lx, count=%d\n",
> 			       page,
> 			       page_to_pfn(page),
> 			       page->flags,
> 			       atomic_read(&page->_count));
> 		}
>
> And I get:
>
> [ 1013.864201] PAGE ffff810001000000 (pfn=0): flags=0, count=0
>
> So at least no one is using that page. Still it is not clear why it
> doesn't have the reserve flag turned on.

My hunch is that it might have something to do with the difference
in the e820 map.  The original map reports that whole page as
being usable while in the kexec case the memory from 0x100 is
reported as being usable.  Perhaps someone has a rounding error?

Eric
-
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/