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: <1331923006.4041.30.camel@mfleming-mobl1.ger.corp.intel.com>
Date:	Fri, 16 Mar 2012 18:36:46 +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 Thu, 2012-03-15 at 10:54 -0700, Yinghai Lu wrote:
> >                if (end <= max_low_pfn << PAGE_SHIFT)
> >                        max_low_pfn_mapped = last_pfn_mapped;
> 
> why max_low_pfn is used here?

The idea is that we only want to update max_low_pfn_mapped when we've
mapped a region at or below max_low_pfn. This maintains compatibility
with behaviour prior to this patch.

> > The max_low_pfn checks are only for CONFIG_X86_32 so that the behaviour
> > is the same as before this patch, i.e. we don't try to map above
> > max_low_pfn.
> 
> ok, to simplify the code, in setup.c you could move
> #ifdef CONFIG_X86_64
>         if (max_pfn > max_low_pfn) {
>                 /* can we preseve max_low_pfn ?*/
>                 max_low_pfn = max_pfn;
>         }
> #endif
> 
> before calling new init_memory_mapping()...
> 
> so you could remove the #idef. in init_memory_mapping.

Hmm.. if we do this then max_low_pfn_mapped will be set to max_pfn on
CONFIG_X86_64 by the time we've finished looping in
init_memory_mapping(). This is not how things work currently. Will that
cause a problem?

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