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: <CAE9FiQWFpsZotawqPD4738jTayB=KOGo0W9+AT2go3GYk1v_sQ@mail.gmail.com>
Date:	Wed, 22 Feb 2012 18:20:01 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	mingo@...hat.com, hpa@...or.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, matt.fleming@...el.com, tglx@...utronix.de
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, efi: Delete efi_ioremap() and fix
 CONFIG_X86_32 oops

On Wed, Feb 22, 2012 at 5:16 PM, tip-bot for Matt Fleming
<matt.fleming@...el.com> wrote:
> Commit-ID:  f75bd1837564657b21431e44243e064a77276589
> Gitweb:     http://git.kernel.org/tip/f75bd1837564657b21431e44243e064a77276589
> Author:     Matt Fleming <matt.fleming@...el.com>
> AuthorDate: Mon, 20 Feb 2012 13:30:26 +0000
> Committer:  H. Peter Anvin <hpa@...or.com>
> CommitDate: Wed, 22 Feb 2012 14:49:55 -0800
>
> x86, efi: Delete efi_ioremap() and fix CONFIG_X86_32 oops
>
...
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index d7d5099..e22bb08 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -690,6 +690,8 @@ early_param("reservelow", parse_reservelow);
>
>  void __init setup_arch(char **cmdline_p)
>  {
> +       unsigned long end_pfn;
> +
>  #ifdef CONFIG_X86_32
>        memcpy(&boot_cpu_data, &new_cpu_data, sizeof(new_cpu_data));
>        visws_early_detect();
> @@ -926,7 +928,24 @@ void __init setup_arch(char **cmdline_p)
>        init_gbpages();
>
>        /* max_pfn_mapped is updated here */
> -       max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn<<PAGE_SHIFT);
> +       end_pfn = max_low_pfn;
> +
> +#ifdef CONFIG_X86_64
> +       /*
> +        * There may be regions after the last E820_RAM region that we
> +        * want to include in the kernel direct mapping because their
> +        * contents are needed at runtime.
> +        */
> +       if (efi_enabled) {
> +               unsigned long efi_end;
> +
> +               efi_end = e820_end_pfn(MAXMEM>>PAGE_SHIFT, E820_RESERVED_EFI);

> +               if (efi_end > end_pfn)
> +                       end_pfn = efi_end;
> +       }
> +#endif
> +
> +       max_low_pfn_mapped = init_memory_mapping(0, end_pfn << PAGE_SHIFT);


Why is MAXMEM used here?

EFI reserved area could be above 4G?

if that is the case, you will map all mmio hole below 4g.

        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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ