1. 08 11月, 2016 8 次提交
  2. 27 10月, 2016 2 次提交
    • H
      arm64/numa: fix incorrect log for memory-less node · 3f7a09f4
      Hanjun Guo 提交于
      When booting on NUMA system with memory-less node (no
      memory dimm on this memory controller), the print
      for setup_node_data() is incorrect:
      
      NUMA: Initmem setup node 2 [mem 0x00000000-0xffffffffffffffff]
      
      It can be fixed by printing [mem 0x00000000-0x00000000] when
      end_pfn is 0, but print <memory-less node> will be more useful.
      
      Fixes: 1a2db300 ("arm64, numa: Add NUMA support for arm64 platforms.")
      Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yisheng Xie <xieyisheng1@huawei.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      3f7a09f4
    • Y
      arm64/numa: fix pcpu_cpu_distance() to get correct CPU proximity · 26984c3b
      Yisheng Xie 提交于
      The pcpu_build_alloc_info() function group CPUs according to their
      proximity, by call callback function @cpu_distance_fn from different
      ARCHs.
      
      For arm64 the callback of @cpu_distance_fn is
          pcpu_cpu_distance(from, to)
              -> node_distance(from, to)
      The @from and @to for function node_distance() should be nid.
      
      However, pcpu_cpu_distance() in arch/arm64/mm/numa.c just past the
      cpu id for @from and @to, and didn't convert to numa node id.
      
      For this incorrect cpu proximity get from ARCH, it may cause each CPU
      in one group and make group_cnt out of bound:
      
      	setup_per_cpu_areas()
      		pcpu_embed_first_chunk()
      			pcpu_build_alloc_info()
      in pcpu_build_alloc_info, since cpu_distance_fn will return
      REMOTE_DISTANCE if we pass cpu ids (0,1,2...), so
      cpu_distance_fn(cpu, tcpu) > LOCAL_DISTANCE will wrongly be ture.
      
      This may results in triggering the BUG_ON(unit != nr_units) later:
      
      [    0.000000] kernel BUG at mm/percpu.c:1916!
      [    0.000000] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc1-00003-g14155caf-dirty #26
      [    0.000000] Hardware name: Hisilicon Hi1616 Evaluation Board (DT)
      [    0.000000] task: ffff000008d6e900 task.stack: ffff000008d60000
      [    0.000000] PC is at pcpu_embed_first_chunk+0x420/0x704
      [    0.000000] LR is at pcpu_embed_first_chunk+0x3bc/0x704
      [    0.000000] pc : [<ffff000008c754f4>] lr : [<ffff000008c75490>] pstate: 800000c5
      [    0.000000] sp : ffff000008d63eb0
      [    0.000000] x29: ffff000008d63eb0 [    0.000000] x28: 0000000000000000
      [    0.000000] x27: 0000000000000040 [    0.000000] x26: ffff8413fbfcef00
      [    0.000000] x25: 0000000000000042 [    0.000000] x24: 0000000000000042
      [    0.000000] x23: 0000000000001000 [    0.000000] x22: 0000000000000046
      [    0.000000] x21: 0000000000000001 [    0.000000] x20: ffff000008cb3bc8
      [    0.000000] x19: ffff8413fbfcf570 [    0.000000] x18: 0000000000000000
      [    0.000000] x17: ffff000008e49ae0 [    0.000000] x16: 0000000000000003
      [    0.000000] x15: 000000000000001e [    0.000000] x14: 0000000000000004
      [    0.000000] x13: 0000000000000000 [    0.000000] x12: 000000000000006f
      [    0.000000] x11: 00000413fbffff00 [    0.000000] x10: 0000000000000004
      [    0.000000] x9 : 0000000000000000 [    0.000000] x8 : 0000000000000001
      [    0.000000] x7 : ffff8413fbfcf63c [    0.000000] x6 : ffff000008d65d28
      [    0.000000] x5 : ffff000008d65e50 [    0.000000] x4 : 0000000000000000
      [    0.000000] x3 : ffff000008cb3cc8 [    0.000000] x2 : 0000000000000040
      [    0.000000] x1 : 0000000000000040 [    0.000000] x0 : 0000000000000000
      [...]
      [    0.000000] Call trace:
      [    0.000000] Exception stack(0xffff000008d63ce0 to 0xffff000008d63e10)
      [    0.000000] 3ce0: ffff8413fbfcf570 0001000000000000 ffff000008d63eb0 ffff000008c754f4
      [    0.000000] 3d00: ffff000008d63d50 ffff0000081af210 00000413fbfff010 0000000000001000
      [    0.000000] 3d20: ffff000008d63d50 ffff0000081af220 00000413fbfff010 0000000000001000
      [    0.000000] 3d40: 00000413fbfcef00 0000000000000004 ffff000008d63db0 ffff0000081af390
      [    0.000000] 3d60: 00000413fbfcef00 0000000000001000 0000000000000000 0000000000001000
      [    0.000000] 3d80: 0000000000000000 0000000000000040 0000000000000040 ffff000008cb3cc8
      [    0.000000] 3da0: 0000000000000000 ffff000008d65e50 ffff000008d65d28 ffff8413fbfcf63c
      [    0.000000] 3dc0: 0000000000000001 0000000000000000 0000000000000004 00000413fbffff00
      [    0.000000] 3de0: 000000000000006f 0000000000000000 0000000000000004 000000000000001e
      [    0.000000] 3e00: 0000000000000003 ffff000008e49ae0
      [    0.000000] [<ffff000008c754f4>] pcpu_embed_first_chunk+0x420/0x704
      [    0.000000] [<ffff000008c6658c>] setup_per_cpu_areas+0x38/0xc8
      [    0.000000] [<ffff000008c608d8>] start_kernel+0x10c/0x390
      [    0.000000] [<ffff000008c601d8>] __primary_switched+0x5c/0x64
      [    0.000000] Code: b8018660 17ffffd7 6b16037f 54000080 (d4210000)
      [    0.000000] ---[ end trace 0000000000000000 ]---
      [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
      
      Fix by getting cpu's node id with early_cpu_to_node() then pass it
      to node_distance() as the original intention.
      
      Fixes: 7af3a0a9 ("arm64/numa: support HAVE_SETUP_PER_CPU_AREA")
      Signed-off-by: NYisheng Xie <xieyisheng1@huawei.com>
      Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Zhen Lei <thunder.leizhen@huawei.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      26984c3b
  3. 20 10月, 2016 3 次提交
    • M
      arm64: remove pr_cont abuse from mem_init · f7881bd6
      Mark Rutland 提交于
      All the lines printed by mem_init are independent, with each ending with
      a newline. While they logically form a large block, none are actually
      continuations of previous lines.
      
      The kernel-side printk code and the userspace demsg tool differ in their
      handling of KERN_CONT following a newline, and while this isn't always a
      problem kernel-side, it does cause difficulty for userspace. Using
      pr_cont causes the userspace tool to not print line prefix (e.g.
      timestamps) even when following a newline, mis-aligning the output and
      making it harder to read, e.g.
      
      [    0.000000] Virtual kernel memory layout:
      [    0.000000]     modules : 0xffff000000000000 - 0xffff000008000000   (   128 MB)
          vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000   (129022 GB)
            .text : 0xffff000008080000 - 0xffff0000088b0000   (  8384 KB)
          .rodata : 0xffff0000088b0000 - 0xffff000008c50000   (  3712 KB)
            .init : 0xffff000008c50000 - 0xffff000008d50000   (  1024 KB)
            .data : 0xffff000008d50000 - 0xffff000008e25200   (   853 KB)
             .bss : 0xffff000008e25200 - 0xffff000008e6bec0   (   284 KB)
          fixed   : 0xffff7dfffe7fd000 - 0xffff7dfffec00000   (  4108 KB)
          PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000   (    16 MB)
          vmemmap : 0xffff7e0000000000 - 0xffff800000000000   (  2048 GB maximum)
                    0xffff7e0000000000 - 0xffff7e0026000000   (   608 MB actual)
          memory  : 0xffff800000000000 - 0xffff800980000000   ( 38912 MB)
      [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
      
      Fix this by using pr_notice consistently for all lines, which both the
      kernel and userspace are happy with.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      f7881bd6
    • J
      arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call · 7209c868
      James Morse 提交于
      Commit 338d4f49 ("arm64: kernel: Add support for Privileged Access
      Never") enabled PAN by enabling the 'SPAN' feature-bit in SCTLR_EL1.
      This means the PSTATE.PAN bit won't be set until the next return to the
      kernel from userspace. On a preemptible kernel we may schedule work that
      accesses userspace on a CPU before it has done this.
      
      Now that cpufeature enable() calls are scheduled via stop_machine(), we
      can set PSTATE.PAN from the cpu_enable_pan() call.
      
      Add WARN_ON_ONCE(in_interrupt()) to check the PSTATE value we updated
      is not immediately discarded.
      Reported-by: NTony Thompson <anthony.thompson@arm.com>
      Reported-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      [will: fixed typo in comment]
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      7209c868
    • J
      arm64: cpufeature: Schedule enable() calls instead of calling them via IPI · 2a6dcb2b
      James Morse 提交于
      The enable() call for a cpufeature/errata is called using on_each_cpu().
      This issues a cross-call IPI to get the work done. Implicitly, this
      stashes the running PSTATE in SPSR when the CPU receives the IPI, and
      restores it when we return. This means an enable() call can never modify
      PSTATE.
      
      To allow PAN to do this, change the on_each_cpu() call to use
      stop_machine(). This schedules the work on each CPU which allows
      us to modify PSTATE.
      
      This involves changing the protype of all the enable() functions.
      
      enable_cpu_capabilities() is called during boot and enables the feature
      on all online CPUs. This path now uses stop_machine(). CPU features for
      hotplug'd CPUs are enabled by verify_local_cpu_features() which only
      acts on the local CPU, and can already modify the running PSTATE as it
      is called from secondary_start_kernel().
      Reported-by: NTony Thompson <anthony.thompson@arm.com>
      Reported-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      2a6dcb2b
  4. 20 9月, 2016 1 次提交
  5. 16 9月, 2016 1 次提交
  6. 12 9月, 2016 1 次提交
    • M
      arm64: use alternative auto-nop · 6ba3b554
      Mark Rutland 提交于
      Make use of the new alternative_if and alternative_else_nop_endif and
      get rid of our homebew NOP sleds, making the code simpler to read.
      
      Note that for cpu_do_switch_mm the ret has been moved out of the
      alternative sequence, and in the default case there will be three
      additional NOPs executed.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      6ba3b554
  7. 09 9月, 2016 5 次提交
  8. 07 9月, 2016 1 次提交
  9. 03 9月, 2016 1 次提交
  10. 26 8月, 2016 3 次提交
    • J
      arm64: hibernate: Support DEBUG_PAGEALLOC · 5ebe3a44
      James Morse 提交于
      DEBUG_PAGEALLOC removes the valid bit of page table entries to prevent
      any access to unallocated memory. Hibernate uses this as a hint that those
      pages don't need to be saved/restored. This patch adds the
      kernel_page_present() function it uses.
      
      hibernate.c copies the resume kernel's linear map for use during restore.
      Add _copy_pte() to fill-in the holes made by DEBUG_PAGEALLOC in the resume
      kernel, so we can restore data the original kernel had at these addresses.
      
      Finally, DEBUG_PAGEALLOC means the linear-map alias of KERNEL_START to
      KERNEL_END may have holes in it, so we can't lazily clean this whole
      area to the PoC. Only clean the new mmuoff region, and the kernel/kvm
      idmaps.
      
      This reverts commit da24eb1f.
      Reported-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      5ebe3a44
    • J
      arm64: vmlinux.ld: Add mmuoff data sections and move mmuoff text into idmap · b6113038
      James Morse 提交于
      Resume from hibernate needs to clean any text executed by the kernel with
      the MMU off to the PoC. Collect these functions together into the
      .idmap.text section as all this code is tightly coupled and also needs
      the same cleaning after resume.
      
      Data is more complicated, secondary_holding_pen_release is written with
      the MMU on, clean and invalidated, then read with the MMU off. In contrast
      __boot_cpu_mode is written with the MMU off, the corresponding cache line
      is invalidated, so when we read it with the MMU on we don't get stale data.
      These cache maintenance operations conflict with each other if the values
      are within a Cache Writeback Granule (CWG) of each other.
      Collect the data into two sections .mmuoff.data.read and .mmuoff.data.write,
      the linker script ensures mmuoff.data.write section is aligned to the
      architectural maximum CWG of 2KB.
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      b6113038
    • C
      arm64: Introduce execute-only page access permissions · cab15ce6
      Catalin Marinas 提交于
      The ARMv8 architecture allows execute-only user permissions by clearing
      the PTE_UXN and PTE_USER bits. However, the kernel running on a CPU
      implementation without User Access Override (ARMv8.2 onwards) can still
      access such page, so execute-only page permission does not protect
      against read(2)/write(2) etc. accesses. Systems requiring such
      protection must enable features like SECCOMP.
      
      This patch changes the arm64 __P100 and __S100 protection_map[] macros
      to the new __PAGE_EXECONLY attributes. A side effect is that
      pte_user() no longer triggers for __PAGE_EXECONLY since PTE_USER isn't
      set. To work around this, the check is done on the PTE_NG bit via the
      pte_ng() macro. VM_READ is also checked now for page faults.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      cab15ce6
  11. 22 8月, 2016 2 次提交
    • J
      arm64: apply __ro_after_init to some objects · 5a9e3e15
      Jisheng Zhang 提交于
      These objects are set during initialization, thereafter are read only.
      
      Previously I only want to mark vdso_pages, vdso_spec, vectors_page and
      cpu_ops as __read_mostly from performance point of view. Then inspired
      by Kees's patch[1] to apply more __ro_after_init for arm, I think it's
      better to mark them as __ro_after_init. What's more, I find some more
      objects are also read only after init. So apply __ro_after_init to all
      of them.
      
      This patch also removes global vdso_pagelist and tries to clean up
      vdso_spec[] assignment code.
      
      [1] http://www.spinics.net/lists/arm-kernel/msg523188.htmlAcked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      5a9e3e15
    • K
      arm64: mm: convert __dma_* routines to use start, size · d34fdb70
      Kwangwoo Lee 提交于
      __dma_* routines have been converted to use start and size instread of
      start and end addresses. The patch was origianlly for adding
      __clean_dcache_area_poc() which will be used in pmem driver to clean
      dcache to the PoC(Point of Coherency) in arch_wb_cache_pmem().
      
      The functionality of __clean_dcache_area_poc()  was equivalent to
      __dma_clean_range(). The difference was __dma_clean_range() uses the end
      address, but __clean_dcache_area_poc() uses the size to clean.
      
      Thus, __clean_dcache_area_poc() has been revised with a fallthrough
      function of __dma_clean_range() after the change that __dma_* routines
      use start and size instead of using start and end.
      
      As a consequence of using start and size, the name of __dma_* routines
      has also been altered following the terminology below:
          area: takes a start and size
          range: takes a start and end
      Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NKwangwoo Lee <kwangwoo.lee@sk.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      d34fdb70
  12. 18 8月, 2016 2 次提交
    • C
      arm64: Fix shift warning in arch/arm64/mm/dump.c · a93a4d62
      Catalin Marinas 提交于
      When building with 48-bit VAs and 16K page configuration, it's possible
      to get the following warning when building the arm64 page table dumping
      code:
      
      arch/arm64/mm/dump.c: In function ‘walk_pud’:
      arch/arm64/mm/dump.c:274:102: warning: right shift count >= width of type [-Wshift-count-overflow]
      
      This is because pud_offset(pgd, 0) performs a shift to the right by 36
      while the value 0 has the type 'int' by default, therefore 32-bit.
      
      This patch modifies all the p*_offset() uses in arch/arm64/mm/dump.c to
      use 0UL for the address argument.
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      a93a4d62
    • C
      arm64: Fix NUMA build error when !CONFIG_ACPI · bfe6c8a8
      Catalin Marinas 提交于
      Since asm/acpi.h is only included by linux/acpi.h when CONFIG_ACPI is
      enabled, disabling the latter leads to the following build error on
      arm64:
      
      arch/arm64/mm/numa.c: In function ‘arm64_numa_init’:
      arch/arm64/mm/numa.c:395:24: error: ‘arm64_acpi_numa_init’ undeclared (first use in this function)
         if (!acpi_disabled && !numa_init(arm64_acpi_numa_init))
      
      This patch include the asm/acpi.h explicitly in arch/arm64/mm/numa.c for
      the arm64_acpi_numa_init() definition.
      
      Fixes: d8b47fca ("arm64, ACPI, NUMA: NUMA support based on SRAT and SLIT")
      Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      bfe6c8a8
  13. 13 8月, 2016 1 次提交
    • L
      arm64: Handle el1 synchronous instruction aborts cleanly · 9adeb8e7
      Laura Abbott 提交于
      Executing from a non-executable area gives an ugly message:
      
      lkdtm: Performing direct entry EXEC_RODATA
      lkdtm: attempting ok execution at ffff0000084c0e08
      lkdtm: attempting bad execution at ffff000008880700
      Bad mode in Synchronous Abort handler detected on CPU2, code 0x8400000e -- IABT (current EL)
      CPU: 2 PID: 998 Comm: sh Not tainted 4.7.0-rc2+ #13
      Hardware name: linux,dummy-virt (DT)
      task: ffff800077e35780 ti: ffff800077970000 task.ti: ffff800077970000
      PC is at lkdtm_rodata_do_nothing+0x0/0x8
      LR is at execute_location+0x74/0x88
      
      The 'IABT (current EL)' indicates the error but it's a bit cryptic
      without knowledge of the ARM ARM. There is also no indication of the
      specific address which triggered the fault. The increase in kernel
      page permissions makes hitting this case more likely as well.
      Handling the case in the vectors gives a much more familiar looking
      error message:
      
      lkdtm: Performing direct entry EXEC_RODATA
      lkdtm: attempting ok execution at ffff0000084c0840
      lkdtm: attempting bad execution at ffff000008880680
      Unable to handle kernel paging request at virtual address ffff000008880680
      pgd = ffff8000089b2000
      [ffff000008880680] *pgd=00000000489b4003, *pud=0000000048904003, *pmd=0000000000000000
      Internal error: Oops: 8400000e [#1] PREEMPT SMP
      Modules linked in:
      CPU: 1 PID: 997 Comm: sh Not tainted 4.7.0-rc1+ #24
      Hardware name: linux,dummy-virt (DT)
      task: ffff800077f9f080 ti: ffff800008a1c000 task.ti: ffff800008a1c000
      PC is at lkdtm_rodata_do_nothing+0x0/0x8
      LR is at execute_location+0x74/0x88
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NLaura Abbott <labbott@redhat.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      9adeb8e7
  14. 04 8月, 2016 1 次提交
    • K
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski 提交于
      The dma-mapping core and the implementations do not change the DMA
      attributes passed by pointer.  Thus the pointer can point to const data.
      However the attributes do not have to be a bitfield.  Instead unsigned
      long will do fine:
      
      1. This is just simpler.  Both in terms of reading the code and setting
         attributes.  Instead of initializing local attributes on the stack
         and passing pointer to it to dma_set_attr(), just set the bits.
      
      2. It brings safeness and checking for const correctness because the
         attributes are passed by value.
      
      Semantic patches for this change (at least most of them):
      
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
      
          @@
          f(...,
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          {
          ...
          }
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      and
      
          // Options: --all-includes
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
          type t;
      
          @@
          t f(..., struct dma_attrs *attrs);
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: NRobin Murphy <robin.murphy@arm.com>
      Acked-by: NHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
      Acked-by: Mark Salter <msalter@redhat.com> [c6x]
      Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
      Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
      Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
      Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
      Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
      Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
      Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      00085f1e
  15. 01 8月, 2016 1 次提交
  16. 29 7月, 2016 1 次提交
    • D
      arm64:acpi: fix the acpi alignment exception when 'mem=' specified · cb0a6502
      Dennis Chen 提交于
      When booting an ACPI enabled kernel with 'mem=x', there is the
      possibility that ACPI data regions from the firmware will lie above the
      memory limit.  Ordinarily these will be removed by
      memblock_enforce_memory_limit(.).
      
      Unfortunately, this means that these regions will then be mapped by
      acpi_os_ioremap(.) as device memory (instead of normal) thus unaligned
      accessess will then provoke alignment faults.
      
      In this patch we adopt memblock_mem_limit_remove_map instead, and this
      preserves these ACPI data regions (marked NOMAP) thus ensuring that
      these regions are not mapped as device memory.
      
      For example, below is an alignment exception observed on ARM platform
      when booting the kernel with 'acpi=on mem=8G':
      
        ...
        Unable to handle kernel paging request at virtual address ffff0000080521e7
        pgd = ffff000008aa0000
        [ffff0000080521e7] *pgd=000000801fffe003, *pud=000000801fffd003, *pmd=000000801fffc003, *pte=00e80083ff1c1707
        Internal error: Oops: 96000021 [#1] PREEMPT SMP
        Modules linked in:
        CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc3-next-20160616+ #172
        Hardware name: AMD Overdrive/Supercharger/Default string, BIOS ROD1001A 02/09/2016
        task: ffff800001ef0000 ti: ffff800001ef8000 task.ti: ffff800001ef8000
        PC is at acpi_ns_lookup+0x520/0x734
        LR is at acpi_ns_lookup+0x4a4/0x734
        pc : [<ffff0000083b8b10>] lr : [<ffff0000083b8a94>] pstate: 60000045
        sp : ffff800001efb8b0
        x29: ffff800001efb8c0 x28: 000000000000001b
        x27: 0000000000000001 x26: 0000000000000000
        x25: ffff800001efb9e8 x24: ffff000008a10000
        x23: 0000000000000001 x22: 0000000000000001
        x21: ffff000008724000 x20: 000000000000001b
        x19: ffff0000080521e7 x18: 000000000000000d
        x17: 00000000000038ff x16: 0000000000000002
        x15: 0000000000000007 x14: 0000000000007fff
        x13: ffffff0000000000 x12: 0000000000000018
        x11: 000000001fffd200 x10: 00000000ffffff76
        x9 : 000000000000005f x8 : ffff000008725fa8
        x7 : ffff000008a8df70 x6 : ffff000008a8df70
        x5 : ffff000008a8d000 x4 : 0000000000000010
        x3 : 0000000000000010 x2 : 000000000000000c
        x1 : 0000000000000006 x0 : 0000000000000000
        ...
          acpi_ns_lookup+0x520/0x734
          acpi_ds_load1_begin_op+0x174/0x4fc
          acpi_ps_build_named_op+0xf8/0x220
          acpi_ps_create_op+0x208/0x33c
          acpi_ps_parse_loop+0x204/0x838
          acpi_ps_parse_aml+0x1bc/0x42c
          acpi_ns_one_complete_parse+0x1e8/0x22c
          acpi_ns_parse_table+0x8c/0x128
          acpi_ns_load_table+0xc0/0x1e8
          acpi_tb_load_namespace+0xf8/0x2e8
          acpi_load_tables+0x7c/0x110
          acpi_init+0x90/0x2c0
          do_one_initcall+0x38/0x12c
          kernel_init_freeable+0x148/0x1ec
          kernel_init+0x10/0xec
          ret_from_fork+0x10/0x40
        Code: b9009fbc 2a00037b 36380057 3219037b (b9400260)
        ---[ end trace 03381e5eb0a24de4 ]---
        Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      
      With 'efi=debug', we can see those ACPI regions loaded by firmware on
      that board as:
      
        efi:   0x0083ff185000-0x0083ff1b4fff [Reserved           |   |  |  |  |  |  |  |   |WB|WT|WC|UC]*
        efi:   0x0083ff1b5000-0x0083ff1c2fff [ACPI Reclaim Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]*
        efi:   0x0083ff223000-0x0083ff224fff [ACPI Memory NVS    |   |  |  |  |  |  |  |   |WB|WT|WC|UC]*
      
      Link: http://lkml.kernel.org/r/1468475036-5852-3-git-send-email-dennis.chen@arm.comAcked-by: NSteve Capper <steve.capper@arm.com>
      Signed-off-by: NDennis Chen <dennis.chen@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Rafael J. Wysocki <rafael@kernel.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Kaly Xin <kaly.xin@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cb0a6502
  17. 27 7月, 2016 1 次提交
  18. 26 7月, 2016 2 次提交
  19. 19 7月, 2016 2 次提交
    • W
      arm64: debug: unmask PSTATE.D earlier · 2ce39ad1
      Will Deacon 提交于
      Clearing PSTATE.D is one of the requirements for generating a debug
      exception. The arm64 booting protocol requires that PSTATE.D is set,
      since many of the debug registers (for example, the hw_breakpoint
      registers) are UNKNOWN out of reset and could potentially generate
      spurious, fatal debug exceptions in early boot code if PSTATE.D was
      clear. Once the debug registers have been safely initialised, PSTATE.D
      is cleared, however this is currently broken for two reasons:
      
      (1) The boot CPU clears PSTATE.D in a postcore_initcall and secondary
          CPUs clear PSTATE.D in secondary_start_kernel. Since the initcall
          runs after SMP (and the scheduler) have been initialised, there is
          no guarantee that it is actually running on the boot CPU. In this
          case, the boot CPU is left with PSTATE.D set and is not capable of
          generating debug exceptions.
      
      (2) In a preemptible kernel, we may explicitly schedule on the IRQ
          return path to EL1. If an IRQ occurs with PSTATE.D set in the idle
          thread, then we may schedule the kthread_init thread, run the
          postcore_initcall to clear PSTATE.D and then context switch back
          to the idle thread before returning from the IRQ. The exception
          return path will then restore PSTATE.D from the stack, and set it
          again.
      
      This patch fixes the problem by moving the clearing of PSTATE.D earlier
      to proc.S. This has the desirable effect of clearing it in one place for
      all CPUs, long before we have to worry about the scheduler or any
      exception handling. We ensure that the previous reset of MDSCR_EL1 has
      completed before unmasking the exception, so that any spurious
      exceptions resulting from UNKNOWN debug registers are not generated.
      
      Without this patch applied, the kprobes selftests have been seen to fail
      under KVM, where we end up attempting to step the OOL instruction buffer
      with PSTATE.D set and therefore fail to complete the step.
      
      Cc: <stable@vger.kernel.org>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Reported-by: NCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      2ce39ad1
    • S
      arm64: Kprobes with single stepping support · 2dd0e8d2
      Sandeepa Prabhu 提交于
      Add support for basic kernel probes(kprobes) and jump probes
      (jprobes) for ARM64.
      
      Kprobes utilizes software breakpoint and single step debug
      exceptions supported on ARM v8.
      
      A software breakpoint is placed at the probe address to trap the
      kernel execution into the kprobe handler.
      
      ARM v8 supports enabling single stepping before the break exception
      return (ERET), with next PC in exception return address (ELR_EL1). The
      kprobe handler prepares an executable memory slot for out-of-line
      execution with a copy of the original instruction being probed, and
      enables single stepping. The PC is set to the out-of-line slot address
      before the ERET. With this scheme, the instruction is executed with the
      exact same register context except for the PC (and DAIF) registers.
      
      Debug mask (PSTATE.D) is enabled only when single stepping a recursive
      kprobe, e.g.: during kprobes reenter so that probed instruction can be
      single stepped within the kprobe handler -exception- context.
      The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
      any further re-entry is prevented by not calling handlers and the case
      counted as a missed kprobe).
      
      Single stepping from the x-o-l slot has a drawback for PC-relative accesses
      like branching and symbolic literals access as the offset from the new PC
      (slot address) may not be ensured to fit in the immediate value of
      the opcode. Such instructions need simulation, so reject
      probing them.
      
      Instructions generating exceptions or cpu mode change are rejected
      for probing.
      
      Exclusive load/store instructions are rejected too.  Additionally, the
      code is checked to see if it is inside an exclusive load/store sequence
      (code from Pratyush).
      
      System instructions are mostly enabled for stepping, except MSR/MRS
      accesses to "DAIF" flags in PSTATE, which are not safe for
      probing.
      
      This also changes arch/arm64/include/asm/ptrace.h to use
      include/asm-generic/ptrace.h.
      
      Thanks to Steve Capper and Pratyush Anand for several suggested
      Changes.
      Signed-off-by: NSandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
      Signed-off-by: NDavid A. Long <dave.long@linaro.org>
      Signed-off-by: NPratyush Anand <panand@redhat.com>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      2dd0e8d2
  20. 09 7月, 2016 1 次提交
    • L
      arm64: mm: change IOMMU notifier action to attach DMA ops · 16c11325
      Lorenzo Pieralisi 提交于
      Current bus notifier in ARM64 (__iommu_attach_notifier)
      attempts to attach dma_ops to a device on BUS_NOTIFY_ADD_DEVICE
      action notification.
      
      This will cause issues on ACPI based systems, where PCI devices
      can be added before the IOMMUs the devices are attached to
      had a chance to be probed, causing failures on attempts to
      attach dma_ops in that the domain for the respective IOMMU
      may not be set-up yet by the time the bus notifier is run.
      
      Devices dma_ops do not require to be set-up till the matching
      device drivers are probed. This means that instead of running
      the notifier attaching dma_ops to devices (__iommu_attach_notifier)
      on BUS_NOTIFY_ADD_DEVICE action, it can be run just before the
      device driver is bound to the device in question (on action
      BUS_NOTIFY_BIND_DRIVER) so that it is certain that its IOMMU
      group and domain are set-up accordingly at the time the
      notifier is triggered.
      
      This patch changes the notifier action upon which dma_ops
      are attached to devices and defer it to driver binding time,
      so that IOMMU devices have a chance to be probed and to register
      their bus notifiers before the dma_ops attach sequence for a
      device is actually carried out.
      
      As a result we also no longer need worry about racing with
      iommu_bus_notifier(), or about retrying the queue in case devices
      were added too early on DT-based systems, so clean up the notifier
      itself plus the additional workaround from 722ec35f ("arm64:
      dma-mapping: fix handling of devices registered before arch_initcall")
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      [rm: get rid of other now-redundant bits]
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      16c11325