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: <1331815251.15493.108.camel@mfleming-mobl1.ger.corp.intel.com>
Date:	Thu, 15 Mar 2012 12:40:51 +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 Mon, 2012-03-12 at 22:39 -0700, Yinghai Lu wrote:
> On Mon, Mar 12, 2012 at 5:38 AM, Matt Fleming <matt.fleming@...el.com> wrote:
> 
> > Have you tested my patch? Have you hit this bug or is it just from code
> > inspection. I'm starting to feel a bit silly now because I can't see the
> > problem you're describing.
> 
> from code inspection.
> 
> your new init_memory_mapping() will only map mem under max_low_pfn ?

No, that's not true for x86_64, look,

        for (i = 0; i < e820.nr_map; i++) {
                entry = &e820.map[i];
                start = entry->addr;
                end = start + entry->size;

                /* We've already mapped below 1MB */
                if (end < (1 << 20))
                        continue;

                if (start < (1 << 20))
                        start = 1 << 20;
#ifdef CONFIG_X86_32
                /*
                 * The map is sorted, so bail once we hit a region
                 * that's above max_low_pfn.
                 */
                if (start >= max_low_pfn << PAGE_SHIFT)
                        break;

                if (end > max_low_pfn << PAGE_SHIFT)
                        end = max_low_pfn << PAGE_SHIFT;
#endif
                switch (entry->type) {
                case E820_RAM:
                case E820_RESERVED_EFI:
                case E820_ACPI:
                case E820_NVS:
                        last_pfn_mapped = __init_memory_mapping(start, end);
                        break;
                default:
                        continue;
                }

                if (end <= max_low_pfn << PAGE_SHIFT)
                        max_low_pfn_mapped = last_pfn_mapped;
        }

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.

> and before that calling for x86_64, max_low_pfn is not updated to max_pfn yet.
> 
> +       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;
>        }
> 
> Please do find one system with more than 4G to test the code.

I'm ordering some parts so that I can test this out.


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