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]
Date:	Wed, 9 Jul 2008 11:05:46 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Suresh Siddha" <suresh.b.siddha@...el.com>,
	"Jeremy Fitzhardinge" <jeremy@...p.org>
Cc:	"mingo@...e.hu" <mingo@...e.hu>, "hpa@...or.com" <hpa@...or.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped

On Wed, Jul 9, 2008 at 10:56 AM, Suresh Siddha
<suresh.b.siddha@...el.com> wrote:
> On Tue, Jul 08, 2008 at 06:56:38PM -0700, Yinghai Lu wrote:
>> On Tue, Jul 8, 2008 at 5:59 PM, Yinghai Lu <yhlu.kernel@...il.com> wrote:
>> > On Tue, Jul 8, 2008 at 4:08 PM, Suresh Siddha <suresh.b.siddha@...el.com> wrote:
>> >> With out this 64bit tip/master doesn't boot using ACPI on my system.
>> >> ---
>> >>
>> >> max_pfn_mapped should include all e820 entries.
>> >> The direct mapping extends to max_pfn_mapped, so that we can directly access
>> >> apertures, ACPI and other tables without having to play with fixmaps.
>> >>
>> >> With this, my system with 1GB memory boots fine with ACPI enabled.
>> >
>> > so without this patch, your system doesn't boot?
>>
>> how about attached patch?
>>
>> [PATCH] x86: make max_pfn cover acpi table below 4g
>>
>> when system have 4g less ram installed, and acpi table sit
>> near end of ram. make max_pfn cover them too.
>> so 64bit kernel don't need to mess up fixmap
>
> Now the latest 64bit x86 tip/master (latest commit d1f7cb8) doesn't boot
> on any of my test systems :( It gets a very early exception..

fix one panic on Ingo's machine

>
> I can't even revert your max_pfn patch, to see if this early exception is
> caused by this patch.. There seems to be more changes on top of it
> already overnight...
>
> BTW, please explain the need for your patch which has more changes, instead
> of my simple patch which was test booted on 3 different systems with both
> 32bit and 64bit kernels...

try to reduce #ifdef CONFIG_X86_64/32, and make 32/64 at the same page.

could be some regression from early_io_remap unifying from jeremy

please check attached revert patch.

YH


YH

View attachment "revert_unify_early_ioremap.patch" of type "text/x-patch" (6649 bytes)

Powered by blists - more mailing lists