1. 20 Sep, 2016 6 commits
    • Ingo Molnar's avatar
      Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into efi/core · 2ab78a72
      Ingo Molnar authored
      Pull EFI fix from Matt Fleming:
      
       * Fix a boot crash reported by Mike Galbraith and Mike Krinkin. The
         new EFI memory map reservation code didn't align reservations to
         EFI_PAGE_SIZE boundaries causing bogus regions to be inserted into
         the global EFI memory map (Matt Fleming)
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      2ab78a72
    • Ingo Molnar's avatar
      41a66072
    • Ingo Molnar's avatar
      Merge tag 'efi-urgent' of... · 7597cdc0
      Ingo Molnar authored
      Merge tag 'efi-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into efi/urgent
      
      Pull EFI fixes from Matt Fleming:
      
       * Fix a boot hang on large memory machines (multiple terabyte) caused
         by type conversion errors in the x86 PAT code (Matt Fleming)
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7597cdc0
    • Matt Fleming's avatar
      x86/efi: Round EFI memmap reservations to EFI_PAGE_SIZE · 92dc3350
      Matt Fleming authored
      Mike Galbraith reported that his machine started rebooting during boot
      after,
      
        commit 8e80632f ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")
      
      The ESRT table on his machine is 56 bytes and at no point in the
      efi_arch_mem_reserve() call path is that size rounded up to
      EFI_PAGE_SIZE, nor is the start address on an EFI_PAGE_SIZE boundary.
      
      Since the EFI memory map only deals with whole pages, inserting an EFI
      memory region with 56 bytes results in a new entry covering zero
      pages, and completely screws up the calculations for the old regions
      that were trimmed.
      
      Round all sizes upwards, and start addresses downwards, to the nearest
      EFI_PAGE_SIZE boundary.
      
      Additionally, efi_memmap_insert() expects the mem::range::end value to
      be one less than the end address for the region.
      Reported-by: default avatarMike Galbraith <umgwanakikbuti@gmail.com>
      Reported-by: default avatarMike Krinkin <krinkin.m.u@gmail.com>
      Tested-by: default avatarMike Krinkin <krinkin.m.u@gmail.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      92dc3350
    • Matt Fleming's avatar
      x86/efi: Only map RAM into EFI page tables if in mixed-mode · 12976670
      Matt Fleming authored
      Waiman reported that booting with CONFIG_EFI_MIXED enabled on his
      multi-terabyte HP machine results in boot crashes, because the EFI
      region mapping functions loop forever while trying to map those
      regions describing RAM.
      
      While this patch doesn't fix the underlying hang, there's really no
      reason to map EFI_CONVENTIONAL_MEMORY regions into the EFI page tables
      when mixed-mode is not in use at runtime.
      Reported-by: default avatarWaiman Long <waiman.long@hpe.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      CC: Theodore Ts'o <tytso@mit.edu>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Scott J Norton <scott.norton@hpe.com>
      Cc: Douglas Hatch <doug.hatch@hpe.com>
      Cc: <stable@vger.kernel.org> # v4.6+
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      12976670
    • Matt Fleming's avatar
      x86/mm/pat: Prevent hang during boot when mapping pages · e535ec08
      Matt Fleming authored
      There's a mixture of signed 32-bit and unsigned 32-bit and 64-bit data
      types used for keeping track of how many pages have been mapped.
      
      This leads to hangs during boot when mapping large numbers of pages
      (multiple terabytes, as reported by Waiman) because those values are
      interpreted as being negative.
      
      commit 74256377 ("x86/mm/pat: Avoid truncation when converting
      cpa->numpages to address") fixed one of those bugs, but there is
      another lurking in __change_page_attr_set_clr().
      
      Additionally, the return value type for the populate_*() functions can
      return negative values when a large number of pages have been mapped,
      triggering the error paths even though no error occurred.
      
      Consistently use 64-bit types on 64-bit platforms when counting pages.
      Even in the signed case this gives us room for regions 8PiB
      (pebibytes) in size whilst still allowing the usual negative value
      error checking idiom.
      Reported-by: default avatarWaiman Long <waiman.long@hpe.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      CC: Theodore Ts'o <tytso@mit.edu>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Scott J Norton <scott.norton@hpe.com>
      Cc: Douglas Hatch <doug.hatch@hpe.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      e535ec08
  2. 19 Sep, 2016 29 commits
  3. 18 Sep, 2016 5 commits