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]

Message-ID: <1331206127.3539.69.camel@mfleming-mobl1.ger.corp.intel.com>
Date:	Thu, 08 Mar 2012 11:28:47 +0000
From:	Matt Fleming <matt.fleming@...el.com>
To:	Yinghai Lu <yinghai@...nel.org>
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 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.

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