linux-kernel - Re: [tip:x86/urgent] x86, efi: Delete efi_ioremap() and fix CONFIG_X86

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:	Thu, 8 Mar 2012 10:59:05 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Matt Fleming <matt.fleming@...el.com>
Cc:	"H. Peter Anvin" <hpa@...nel.org>, mingo@...hat.com,
	mjg@...hat.com, linux-kernel@...r.kernel.org, keithp@...thp.com,
	rui.zhang@...el.com, huang.ying.caritas@...il.com,
	stable@...r.kernel.org, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, efi: Delete efi_ioremap() and fix
 CONFIG_X86_32 oops

On Thu, Mar 8, 2012 at 3:28 AM, Matt Fleming <matt.fleming@...el.com> wrote:
> On Wed, 2012-03-07 at 10:05 -0800, Yinghai Lu wrote:
>> > -
>> > -       max_low_pfn_mapped = init_memory_mapping(0, end_pfn << PAGE_SHIFT);
>> > -       max_pfn_mapped = max_low_pfn_mapped;
>> > +       /* max_low_pfn_mapped is updated here */
>> > +       max_pfn_mapped = init_memory_mapping();
>> >
>> >  #ifdef CONFIG_X86_64
>> >        if (max_pfn > max_low_pfn) {
>> > -               max_pfn_mapped = init_memory_mapping(1UL<<32,
>> > -                                                    max_pfn<<PAGE_SHIFT);
>> >                /* can we preseve max_low_pfn ?*/
>> >                max_low_pfn = max_pfn;
>> >        }
>>
>> you may need to move those three lines before
>> max_pfn_mapped = init_memory_mapping()
>>
>> otherwise for x86_64, memory from [4G, TOMH) will not be directly mapped.
>
> I'm afraid I don't understand what you mean. The changes in my patch
> mean that init_memory_mapping() doesn't work the way it previously did.
> It will map all the regions in the e820 table and presumably the top of
> memory is contained within one of those regions.
>
> Could you clarify what you think the problem is? Unfortunately I don't
> have a test machine with large amounts of RAM so it's entirely possible
> I've made a mistake somewhere.

in your new init_memory_mapping will only map memory below max_low_pfn.

but the max_low_pfn is under 4g.

So it will be ended up with 4G above memory is not mapped.


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