Messages in this thread | | | Date | Fri, 16 Mar 2012 12:01:40 -0700 | Subject | Re: [tip:x86/urgent] x86, efi: Delete efi_ioremap() and fix CONFIG_X86_32 oops | From | Yinghai Lu <> |
| |
On Fri, Mar 16, 2012 at 11:36 AM, Matt Fleming <matt.fleming@intel.com> wrote: > 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?
oh, before this patch could be applied, you need to make sure all max_low_pfn_mapped reference is removed. current assumption is under max_low_pfn_mapped all mem is mapped. now with this patch, that assumption is not right anymore.
Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |