1. 18 8月, 2018 2 次提交
  2. 17 8月, 2018 2 次提交
    • G
      arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid() · 5ad356ea
      Greg Hackmann 提交于
      ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input
      before seeing if the PFN is valid.  This leads to false positives when
      some of the upper bits are set, but the lower bits match a valid PFN.
      
      For example, the following userspace code looks up a bogus entry in
      /proc/kpageflags:
      
          int pagemap = open("/proc/self/pagemap", O_RDONLY);
          int pageflags = open("/proc/kpageflags", O_RDONLY);
          uint64_t pfn, val;
      
          lseek64(pagemap, [...], SEEK_SET);
          read(pagemap, &pfn, sizeof(pfn));
          if (pfn & (1UL << 63)) {        /* valid PFN */
              pfn &= ((1UL << 55) - 1);   /* clear flag bits */
              pfn |= (1UL << 55);
              lseek64(pageflags, pfn * sizeof(uint64_t), SEEK_SET);
              read(pageflags, &val, sizeof(val));
          }
      
      On ARM64 this causes the userspace process to crash with SIGSEGV rather
      than reading (1 << KPF_NOPAGE).  kpageflags_read() treats the offset as
      valid, and stable_page_flags() will try to access an address between the
      user and kernel address ranges.
      
      Fixes: c1cc1552 ("arm64: MMU initialisation")
      Cc: stable@vger.kernel.org
      Signed-off-by: NGreg Hackmann <ghackmann@google.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      5ad356ea
    • W
      arm64: Avoid calling stop_machine() when patching jump labels · f6cc0c50
      Will Deacon 提交于
      Patching a jump label involves patching a single instruction at a time,
      swizzling between a branch and a NOP. The architecture treats these
      instructions specially, so a concurrently executing CPU is guaranteed to
      see either the NOP or the branch, rather than an amalgamation of the two
      instruction encodings.
      
      However, in order to guarantee that the new instruction is visible, it
      is necessary to send an IPI to the concurrently executing CPU so that it
      discards any previously fetched instructions from its pipeline. This
      operation therefore cannot be completed from a context with IRQs
      disabled, but this is exactly what happens on the jump label path where
      the hotplug lock is held and irqs are subsequently disabled by
      stop_machine_cpuslocked(). This results in a deadlock during boot on
      Hikey-960.
      
      Due to the architectural guarantees around patching NOPs and branches,
      we don't actually need to stop_machine() at all on the jump label path,
      so we can avoid the deadlock by using the "nosync" variant of our
      instruction patching routine.
      
      Fixes: 693350a7 ("arm64: insn: Don't fallback on nosync path for general insn patching")
      Reported-by: NTuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
      Reported-by: NJohn Stultz <john.stultz@linaro.org>
      Tested-by: NValentin Schneider <valentin.schneider@arm.com>
      Tested-by: NTuomas Tynkkynen <tuomas@tuxera.com>
      Tested-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      f6cc0c50
  3. 09 8月, 2018 1 次提交
  4. 08 8月, 2018 1 次提交
  5. 07 8月, 2018 6 次提交
  6. 06 8月, 2018 1 次提交
  7. 03 8月, 2018 3 次提交
  8. 02 8月, 2018 4 次提交
    • C
      kconfig: include kernel/Kconfig.preempt from init/Kconfig · 87a4c375
      Christoph Hellwig 提交于
      Almost all architectures include it.  Add a ARCH_NO_PREEMPT symbol to
      disable preempt support for alpha, hexagon, non-coldfire m68k and
      user mode Linux.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      87a4c375
    • C
      Kconfig: consolidate the "Kernel hacking" menu · 06ec64b8
      Christoph Hellwig 提交于
      Move the source of lib/Kconfig.debug and arch/$(ARCH)/Kconfig.debug to
      the top-level Kconfig.  For two architectures that means moving their
      arch-specific symbols in that menu into a new arch Kconfig.debug file,
      and for a few more creating a dummy file so that we can include it
      unconditionally.
      
      Also move the actual 'Kernel hacking' menu to lib/Kconfig.debug, where
      it belongs.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      06ec64b8
    • C
      kconfig: include common Kconfig files from top-level Kconfig · 1572497c
      Christoph Hellwig 提交于
      Instead of duplicating the source statements in every architecture just
      do it once in the toplevel Kconfig file.
      
      Note that with this the inclusion of arch/$(SRCARCH/Kconfig moves out of
      the top-level Kconfig into arch/Kconfig so that don't violate ordering
      constraits while keeping a sensible menu structure.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      1572497c
    • L
      mm: do not initialize TLB stack vma's with vma_init() · 8b11ec1b
      Linus Torvalds 提交于
      Commit 2c4541e2 ("mm: use vma_init() to initialize VMAs on stack and
      data segments") tried to initialize various left-over ad-hoc vma's
      "properly", but actually made things worse for the temporary vma's used
      for TLB flushing.
      
      vma_init() doesn't actually initialize all of the vma, just a few
      fields, so doing something like
      
         -       struct vm_area_struct vma = { .vm_mm = tlb->mm, };
         +       struct vm_area_struct vma;
         +
         +       vma_init(&vma, tlb->mm);
      
      was actually very bad: instead of having a nicely initialized vma with
      every field but "vm_mm" zeroed, you'd have an entirely uninitialized vma
      with only a couple of fields initialized.  And they weren't even fields
      that the code in question mostly cared about.
      
      The flush_tlb_range() function takes a "struct vma" rather than a
      "struct mm_struct", because a few architectures actually care about what
      kind of range it is - being able to only do an ITLB flush if it's a
      range that doesn't have data accesses enabled, for example.  And all the
      normal users already have the vma for doing the range invalidation.
      
      But a few people want to call flush_tlb_range() with a range they just
      made up, so they also end up using a made-up vma.  x86 just has a
      special "flush_tlb_mm_range()" function for this, but other
      architectures (arm and ia64) do the "use fake vma" thing instead, and
      thus got caught up in the vma_init() changes.
      
      At the same time, the TLB flushing code really doesn't care about most
      other fields in the vma, so vma_init() is just unnecessary and
      pointless.
      
      This fixes things by having an explicit "this is just an initializer for
      the TLB flush" initializer macro, which is used by the arm/arm64/ia64
      people who mis-use this interface with just a dummy vma.
      
      Fixes: 2c4541e2 ("mm: use vma_init() to initialize VMAs on stack and data segments")
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Hugh Dickins <hughd@google.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8b11ec1b
  9. 31 7月, 2018 8 次提交
    • A
      crypto/arm64: aes-ce-gcm - add missing kernel_neon_begin/end pair · c7513c2a
      Ard Biesheuvel 提交于
      Calling pmull_gcm_encrypt_block() requires kernel_neon_begin() and
      kernel_neon_end() to be used since the routine touches the NEON
      register file. Add the missing calls.
      
      Also, since NEON register contents are not preserved outside of
      a kernel mode NEON region, pass the key schedule array again.
      
      Fixes: 7c50136a ("crypto: arm64/aes-ghash - yield NEON after every ...")
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      c7513c2a
    • W
      arm64: kexec: Add comment to explain use of __flush_icache_range() · dcab90d9
      Will Deacon 提交于
      Now that we understand the deadlock arising from flush_icache_range()
      on the kexec crash kernel path, add a comment to justify the use of
      __flush_icache_range() here.
      Reported-by: NDave Kleikamp <dave.kleikamp@oracle.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      dcab90d9
    • W
      arm64: sdei: Mark sdei stack helper functions as static · eab1cecc
      Will Deacon 提交于
      The SDEI stack helper functions are only used by _on_sdei_stack() and
      refer to symbols (e.g. sdei_stack_normal_ptr) that are only defined if
      CONFIG_VMAP_STACK=y.
      
      Mark these functions as static, so we don't run into errors at link-time
      due to references to undefined symbols. Stick all the parameters onto
      the same line whilst we're passing through.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      eab1cecc
    • B
      arm64, kaslr: export offset in VMCOREINFO ELF notes · e401b7c2
      Bhupesh Sharma 提交于
      Include KASLR offset in arm64 VMCOREINFO ELF notes to assist in
      debugging. vmcore parsing in user-space already expects this value in
      the notes and we are providing it for portability of those existing
      tools with x86.
      
      Ideally we would like core code to do this (so that way this
      information won't be missed when an architecture adds KASLR support),
      but mips has CONFIG_RANDOMIZE_BASE, and doesn't provide kaslr_offset(),
      so I am not sure if this is needed for mips (and other such similar arch
      cases in future). So, lets keep this architecture specific for now.
      
      As an example of a user-space use-case, consider the
      makedumpfile user-space utility which will need fixup to use this
      KASLR offset to work with cases where we need to find a way to
      translate symbol address from vmlinux to kernel run time address
      in case of KASLR boot on arm64.
      
      I have already submitted the makedumpfile user-space patch upstream
      and the maintainer has suggested to wait for the kernel changes to be
      included (see [0]).
      
      I tested this on my qualcomm amberwing board both for KASLR and
      non-KASLR boot cases:
      
      Without this patch:
         # cat > scrub.conf << EOF
         [vmlinux]
         erase jiffies
         erase init_task.utime
         for tsk in init_task.tasks.next within task_struct:tasks
             erase tsk.utime
         endfor
         EOF
      
        # makedumpfile --split -d 31 -x vmlinux --config scrub.conf vmcore dumpfile_{1,2,3}
        readpage_elf: Attempt to read non-existent page at 0xffffa8a5bf180000.
        readmem: type_addr: 1, addr:ffffa8a5bf180000, size:8
        vaddr_to_paddr_arm64: Can't read pgd
        readmem: Can't convert a virtual address(ffff0000092a542c) to physical
        address.
        readmem: type_addr: 0, addr:ffff0000092a542c, size:390
        check_release: Can't get the address of system_utsname
      
      After this patch check_release() is ok, and also we are able to erase
      symbol from vmcore (I checked this with kernel 4.18.0-rc4+):
      
        # makedumpfile --split -d 31 -x vmlinux --config scrub.conf vmcore dumpfile_{1,2,3}
        The kernel version is not supported.
        The makedumpfile operation may be incomplete.
        Checking for memory holes                         : [100.0 %] \
        Checking for memory holes                         : [100.0 %] |
        Checking foExcluding unnecessary pages                       : [100.0 %]
        \
        Excluding unnecessary pages                       : [100.0 %] \
      
        The dumpfiles are saved to dumpfile_1, dumpfile_2, and dumpfile_3.
      
        makedumpfile Completed.
      
      [0] https://www.spinics.net/lists/kexec/msg21195.html
      
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Acked-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NBhupesh Sharma <bhsharma@redhat.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      e401b7c2
    • M
      arm64: perf: Add cap_user_time aarch64 · 9d2dcc8f
      Michael O'Farrell 提交于
      It is useful to get the running time of a thread.  Doing so in an
      efficient manner can be important for performance of user applications.
      Avoiding system calls in `clock_gettime` when handling
      CLOCK_THREAD_CPUTIME_ID is important.  Other clocks are handled in the
      VDSO, but CLOCK_THREAD_CPUTIME_ID falls back on the system call.
      
      CLOCK_THREAD_CPUTIME_ID is not handled in the VDSO since it would have
      costs associated with maintaining updated user space accessible time
      offsets.  These offsets have to be updated everytime the a thread is
      scheduled/descheduled.  However, for programs regularly checking the
      running time of a thread, this is a performance improvement.
      
      This patch takes a middle ground, and adds support for cap_user_time an
      optional feature of the perf_event API.  This way costs are only
      incurred when the perf_event api is enabled.  This is done the same way
      as it is in x86.
      
      Ultimately this allows calculating the thread running time in userspace
      on aarch64 as follows (adapted from perf_event_open manpage):
      
      u32 seq, time_mult, time_shift;
      u64 running, count, time_offset, quot, rem, delta;
      struct perf_event_mmap_page *pc;
      pc = buf;  // buf is the perf event mmaped page as documented in the API.
      
      if (pc->cap_usr_time) {
          do {
              seq = pc->lock;
              barrier();
              running = pc->time_running;
      
              count = readCNTVCT_EL0();  // Read ARM hardware clock.
              time_offset = pc->time_offset;
              time_mult   = pc->time_mult;
              time_shift  = pc->time_shift;
      
              barrier();
          } while (pc->lock != seq);
      
          quot = (count >> time_shift);
          rem = count & (((u64)1 << time_shift) - 1);
          delta = time_offset + quot * time_mult +
                  ((rem * time_mult) >> time_shift);
      
          running += delta;
          // running now has the current nanosecond level thread time.
      }
      
      Summary of changes in the patch:
      
      For aarch64 systems, make arch_perf_update_userpage update the timing
      information stored in the perf_event page.  Requiring the following
      calculations:
        - Calculate the appropriate time_mult, and time_shift factors to convert
          ticks to nano seconds for the current clock frequency.
        - Adjust the mult and shift factors to avoid shift factors of 32 bits.
          (possibly unnecessary)
        - The time_offset userspace should apply when doing calculations:
          negative the current sched time (now), because time_running and
          time_enabled fields of the perf_event page have just been updated.
      Toggle bits to appropriate values:
        - Enable cap_user_time
      Signed-off-by: NMichael O'Farrell <micpof@gmail.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      9d2dcc8f
    • A
      arm64: drop unused kernel_neon_begin_partial() macro · d26de6c9
      Ard Biesheuvel 提交于
      When kernel mode NEON was first introduced to the arm64 kernel,
      every call to kernel_neon_begin()/_end() stacked resp. unstacked
      the entire NEON register file, making it worthwile to reduce the
      number of used NEON registers to a bare minimum, and only stack
      those. kernel_neon_begin_partial() was introduced for this purpose,
      but after the refactoring for SVE and other changes, it no longer
      exists and was simply #define'd to kernel_neon_begin() directly.
      
      In the mean time, all users have been updated, so let's remove
      the fallback macro.
      Reviewed-by: NDave Martin <Dave.Martin@arm.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      d26de6c9
    • D
      arm64: kexec: machine_kexec should call __flush_icache_range · 140aada4
      Dave Kleikamp 提交于
      machine_kexec flushes the reboot_code_buffer from the icache
      after stopping the other cpus.
      
      Commit 3b8c9f1c ("arm64: IPI each CPU after invalidating the I-cache
      for kernel mappings") added an IPI call to flush_icache_range, which
      causes a hang here, so replace the call with __flush_icache_range
      Signed-off-by: NDave Kleikamp <dave.kleikamp@oracle.com>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      140aada4
    • W
      arm64: svc: Ensure hardirq tracing is updated before return · efd11235
      Will Deacon 提交于
      We always run userspace with interrupts enabled, but with the recent
      conversion of the syscall entry/exit code to C, we don't inform the
      hardirq tracing code that interrupts are about to become enabled by
      virtue of restoring the EL0 SPSR.
      
      This patch ensures that trace_hardirqs_on() is called on the syscall
      return path when we return to the assembly code with interrupts still
      disabled.
      
      Fixes: f37099b6 ("arm64: convert syscall trace logic to C")
      Reported-by: NJulien Grall <julien.grall@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      efd11235
  10. 27 7月, 2018 3 次提交
  11. 26 7月, 2018 2 次提交
  12. 25 7月, 2018 2 次提交
    • J
      arm64: fix vmemmap BUILD_BUG_ON() triggering on !vmemmap setups · 7b0eb6b4
      Johannes Weiner 提交于
      Arnd reports the following arm64 randconfig build error with the PSI
      patches that add another page flag:
      
        /git/arm-soc/arch/arm64/mm/init.c: In function 'mem_init':
        /git/arm-soc/include/linux/compiler.h:357:38: error: call to
        '__compiletime_assert_618' declared with attribute error: BUILD_BUG_ON
        failed: sizeof(struct page) > (1 << STRUCT_PAGE_MAX_SHIFT)
      
      The additional page flag causes other information stored in
      page->flags to get bumped into their own struct page member:
      
        #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT <=
        BITS_PER_LONG - NR_PAGEFLAGS
        #define LAST_CPUPID_WIDTH LAST_CPUPID_SHIFT
        #else
        #define LAST_CPUPID_WIDTH 0
        #endif
      
        #if defined(CONFIG_NUMA_BALANCING) && LAST_CPUPID_WIDTH == 0
        #define LAST_CPUPID_NOT_IN_PAGE_FLAGS
        #endif
      
      which in turn causes the struct page size to exceed the size set in
      STRUCT_PAGE_MAX_SHIFT. This value is an an estimate used to size the
      VMEMMAP page array according to address space and struct page size.
      
      However, the check is performed - and triggers here - on a !VMEMMAP
      config, which consumes an additional 22 page bits for the sparse
      section id. When VMEMMAP is enabled, those bits are returned, cpupid
      doesn't need its own member, and the page passes the VMEMMAP check.
      
      Restrict that check to the situation it was meant to check: that we
      are sizing the VMEMMAP page array correctly.
      
      Says Arnd:
      
          Further experiments show that the build error already existed before,
          but was only triggered with larger values of CONFIG_NR_CPU and/or
          CONFIG_NODES_SHIFT that might be used in actual configurations but
          not in randconfig builds.
      
          With longer CPU and node masks, I could recreate the problem with
          kernels as old as linux-4.7 when arm64 NUMA support got added.
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Tested-by: NArnd Bergmann <arnd@arndb.de>
      Cc: stable@vger.kernel.org
      Fixes: 1a2db300 ("arm64, numa: Add NUMA support for arm64 platforms.")
      Fixes: 3e1907d5 ("arm64: mm: move vmemmap region right below the linear region")
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      7b0eb6b4
    • D
      arm64: Check for errata before evaluating cpu features · dc0e3658
      Dirk Mueller 提交于
      Since commit d3aec8a2 ("arm64: capabilities: Restrict KPTI
      detection to boot-time CPUs") we rely on errata flags being already
      populated during feature enumeration. The order of errata and
      features was flipped as part of commit ed478b3f ("arm64:
      capabilities: Group handling of features and errata workarounds").
      
      Return to the orginal order of errata and feature evaluation to
      ensure errata flags are present during feature evaluation.
      
      Fixes: ed478b3f ("arm64: capabilities: Group handling of
          features and errata workarounds")
      CC: Suzuki K Poulose <suzuki.poulose@arm.com>
      CC: Marc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NDirk Mueller <dmueller@suse.com>
      Reviewed-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      dc0e3658
  13. 24 7月, 2018 1 次提交
    • A
      arm64: fix ACPI dependencies · 2c870e61
      Arnd Bergmann 提交于
      Kconfig reports a warning on x86 builds after the ARM64 dependency
      was added.
      
      drivers/acpi/Kconfig:6:error: recursive dependency detected!
      drivers/acpi/Kconfig:6:       symbol ACPI depends on EFI
      
      This rephrases the dependency to keep the ARM64 details out of the
      shared Kconfig file, so Kconfig no longer gets confused by it.
      
      For consistency, all three architectures that support ACPI now
      select ARCH_SUPPORTS_ACPI in exactly the configuration in which
      they allow it. We still need the 'default x86', as each one
      wants a different default: default-y on x86, default-n on arm64,
      and always-y on ia64.
      
      Fixes: 5bcd4408 ("drivers: acpi: add dependency of EFI for arm64")
      Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      2c870e61
  14. 23 7月, 2018 4 次提交
    • A
      arm64: acpi: fix alignment fault in accessing ACPI · 09ffcb0d
      AKASHI Takahiro 提交于
      This is a fix against the issue that crash dump kernel may hang up
      during booting, which can happen on any ACPI-based system with "ACPI
      Reclaim Memory."
      
      (kernel messages after panic kicked off kdump)
      	   (snip...)
      	Bye!
      	   (snip...)
      	ACPI: Core revision 20170728
      	pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
      	Internal error: Oops: 96000021 [#1] SMP
      	Modules linked in:
      	CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
      	task: ffff000008d05180 task.stack: ffff000008cc0000
      	PC is at acpi_ns_lookup+0x25c/0x3c0
      	LR is at acpi_ds_load1_begin_op+0xa4/0x294
      	   (snip...)
      	Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
      	Call trace:
      	   (snip...)
      	[<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
      	[<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
      	[<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
      	[<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
      	[<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
      	[<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
      	[<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
      	[<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
      	[<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
      	[<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
      	[<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
      	[<ffff000008badc20>] acpi_early_init+0x9c/0xd0
      	[<ffff000008b70d50>] start_kernel+0x3b4/0x43c
      	Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
      	---[ end trace c46ed37f9651c58e ]---
      	Kernel panic - not syncing: Fatal exception
      	Rebooting in 10 seconds..
      
      (diagnosis)
      * This fault is a data abort, alignment fault (ESR=0x96000021)
        during reading out ACPI table.
      * Initial ACPI tables are normally stored in system ram and marked as
        "ACPI Reclaim memory" by the firmware.
      * After the commit f56ab9a5 ("efi/arm: Don't mark ACPI reclaim
        memory as MEMBLOCK_NOMAP"), those regions are differently handled
        as they are "memblock-reserved", without NOMAP bit.
      * So they are now excluded from device tree's "usable-memory-range"
        which kexec-tools determines based on a current view of /proc/iomem.
      * When crash dump kernel boots up, it tries to accesses ACPI tables by
        mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap()
        since they are no longer part of mapped system ram.
      * Given that ACPI accessor/helper functions are compiled in without
        unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED),
        any unaligned access to ACPI tables can cause a fatal panic.
      
      With this patch, acpi_os_ioremap() always honors memory attribute
      information provided by the firmware (EFI) and retaining cacheability
      allows the kernel safe access to ACPI tables.
      Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
      Reviewed-by: NJames Morse <james.morse@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reported-by and Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      09ffcb0d
    • J
      arm64: export memblock_reserve()d regions via /proc/iomem · 50d7ba36
      James Morse 提交于
      There has been some confusion around what is necessary to prevent kexec
      overwriting important memory regions. memblock: reserve, or nomap?
      Only memblock nomap regions are reported via /proc/iomem, kexec's
      user-space doesn't know about memblock_reserve()d regions.
      
      Until commit f56ab9a5 ("efi/arm: Don't mark ACPI reclaim memory
      as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved
      and thus possible for kexec to overwrite with the new kernel or initrd.
      But this was always broken, as the UEFI memory map is also reserved
      and not marked as nomap.
      
      Exporting both nomap and reserved memblock types is a nuisance as
      they live in different memblock structures which we can't walk at
      the same time.
      
      Take a second walk over memblock.reserved and add new 'reserved'
      subnodes for the memblock_reserved() regions that aren't already
      described by the existing code. (e.g. Kernel Code)
      
      We use reserve_region_with_split() to find the gaps in existing named
      regions. This handles the gap between 'kernel code' and 'kernel data'
      which is memblock_reserve()d, but already partially described by
      request_standard_resources(). e.g.:
      | 80000000-dfffffff : System RAM
      |   80080000-80ffffff : Kernel code
      |   81000000-8158ffff : reserved
      |   81590000-8237efff : Kernel data
      |   a0000000-dfffffff : Crash kernel
      | e00f0000-f949ffff : System RAM
      
      reserve_region_with_split needs kzalloc() which isn't available when
      request_standard_resources() is called, use an initcall.
      Reported-by: NBhupesh Sharma <bhsharma@redhat.com>
      Reported-by: NTyler Baicar <tbaicar@codeaurora.org>
      Suggested-by: NAkashi Takahiro <takahiro.akashi@linaro.org>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Fixes: d28f6df1 ("arm64/kexec: Add core kexec support")
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      CC: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      50d7ba36
    • O
      arm64: build with baremetal linker target instead of Linux when available · c931d34e
      Olof Johansson 提交于
      Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
      in particular. So, probe for whether it's available and use the previous
      (linux) targets if it isn't.
      Reported-by: NLaura Abbott <labbott@redhat.com>
      Tested-by: NLaura Abbott <labbott@redhat.com>
      Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Paul Kocialkowski <contact@paulk.fr>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      c931d34e
    • M
      arm64: fix possible spectre-v1 write in ptrace_hbp_set_event() · 14d6e289
      Mark Rutland 提交于
      It's possible for userspace to control idx. Sanitize idx when using it
      as an array index, to inhibit the potential spectre-v1 write gadget.
      
      Found by smatch.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      14d6e289
新手
引导
客服 返回
顶部