1. 15 Feb, 2017 6 commits
    • Mark Rutland's avatar
      arm64/kprobes: consistently handle MRS/MSR with XZR · ffe7afd1
      Mark Rutland authored
      Now that we have XZR-safe helpers for fiddling with registers, use these
      in the arm64 kprobes code rather than open-coding the logic.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ffe7afd1
    • Mark Rutland's avatar
      arm64: cpufeature: correctly handle MRS to XZR · 521c6461
      Mark Rutland authored
      In emulate_mrs() we may erroneously write back to the user SP rather
      than XZR if we trap an MRS instruction where Xt == 31.
      
      Use the new pt_regs_write_reg() helper to handle this correctly.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Fixes: 77c97b4e ("arm64: cpufeature: Expose CPUID registers by emulation")
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      521c6461
    • Mark Rutland's avatar
      arm64: traps: correctly handle MRS/MSR with XZR · 8b6e70fc
      Mark Rutland authored
      Currently we hand-roll XZR-safe register handling in
      user_cache_maint_handler(), though we forget to do the same in
      ctr_read_handler(), and may erroneously write back to the user SP rather
      than XZR.
      
      Use the new helpers to handle these cases correctly and consistently.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Fixes: 116c81f4 ("arm64: Work around systems with mismatched cache line sizes")
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      8b6e70fc
    • Mark Rutland's avatar
      arm64: ptrace: add XZR-safe regs accessors · 6c23e2ff
      Mark Rutland authored
      In A64, XZR and the SP share the same encoding (31), and whether an
      instruction accesses XZR or SP for a particular register parameter
      depends on the definition of the instruction.
      
      We store the SP in pt_regs::regs[31], and thus when emulating
      instructions, we must be careful to not erroneously read from or write
      back to the saved SP. Unfortunately, we often fail to be this careful.
      
      In all cases, instructions using a transfer register parameter Xt use
      this to refer to XZR rather than SP. This patch adds helpers so that we
      can more easily and consistently handle these cases.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      6c23e2ff
    • Arnd Bergmann's avatar
      arm64: include asm/assembler.h in entry-ftrace.S · f705d954
      Arnd Bergmann authored
      In a randconfig build I ran into this build error:
      
      arch/arm64/kernel/entry-ftrace.S: Assembler messages:
      arch/arm64/kernel/entry-ftrace.S:101: Error: unknown mnemonic `ldr_l' -- `ldr_l x2,ftrace_trace_function'
      
      The macro is defined in asm/assembler.h, so we should include that file.
      
      Fixes: 829d2bd1 ("arm64: entry-ftrace.S: avoid open-coded {adr,ldr}_l")
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      f705d954
    • Arnd Bergmann's avatar
      arm64: fix warning about swapper_pg_dir overflow · 12f043ff
      Arnd Bergmann authored
      With 4 levels of 16KB pages, we get this warning about the fact that we are
      copying a whole page into an array that is declared as having only two pointers
      for the top level of the page table:
      
      arch/arm64/mm/mmu.c: In function 'paging_init':
      arch/arm64/mm/mmu.c:528:2: error: 'memcpy' writing 16384 bytes into a region of size 16 overflows the destination [-Werror=stringop-overflow=]
      
      This is harmless since we actually reserve a whole page in the definition of the
      array that comes from, and just the extern declaration is short. The pgdir
      is initialized to zero either way, so copying the actual entries here seems
      like the best solution.
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      12f043ff
  2. 10 Feb, 2017 1 commit
    • Christopher Covington's avatar
      arm64: Work around Falkor erratum 1003 · 38fd94b0
      Christopher Covington authored
      The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
      using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
      is triggered, page table entries using the new translation table base
      address (BADDR) will be allocated into the TLB using the old ASID. All
      circumstances leading to the incorrect ASID being cached in the TLB arise
      when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
      operation is in the process of performing a translation using the specific
      TTBRx_EL1 being written, and the memory operation uses a translation table
      descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
      ASID is not subject to this erratum because hardware is prohibited from
      performing translations from an out-of-context translation regime.
      
      Consider the following pseudo code.
      
        write new BADDR and ASID values to TTBRx_EL1
      
      Replacing the above sequence with the one below will ensure that no TLB
      entries with an incorrect ASID are used by software.
      
        write reserved value to TTBRx_EL1[ASID]
        ISB
        write new value to TTBRx_EL1[BADDR]
        ISB
        write new value to TTBRx_EL1[ASID]
        ISB
      
      When the above sequence is used, page table entries using the new BADDR
      value may still be incorrectly allocated into the TLB using the reserved
      ASID. Yet this will not reduce functionality, since TLB entries incorrectly
      tagged with the reserved ASID will never be hit by a later instruction.
      
      Based on work by Shanker Donthineni <shankerd@codeaurora.org>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarChristopher Covington <cov@codeaurora.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      38fd94b0
  3. 09 Feb, 2017 4 commits
  4. 08 Feb, 2017 4 commits
  5. 06 Feb, 2017 4 commits
    • Pratyush Anand's avatar
      arm64: do not trace atomic operations · b7eed6dd
      Pratyush Anand authored
      Atomic operation function symbols are exported,when
      CONFIG_ARM64_LSE_ATOMICS is defined. Prefix them with notrace, so that
      an user can not trace these functions. Tracing these functions causes
      kernel crash.
      Signed-off-by: default avatarPratyush Anand <panand@redhat.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      b7eed6dd
    • Dan Carpenter's avatar
      ACPI/IORT: Fix the error return code in iort_add_smmu_platform_device() · 5e5afa6c
      Dan Carpenter authored
      The function iort_add_smmu_platform_device() accidentally returns 0
      (ie PTR_ERR(pdev) where pdev == NULL) if platform_device_alloc() fails;
      fix the bug by returning a proper error value.
      
      Fixes: 846f0e9e ("ACPI/IORT: Add support for ARM SMMU platform devices creation")
      Acked-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      [lorenzo.pieralisi@arm.com: improved commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5e5afa6c
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Fix iort_node_get_id() mapping entries indexing · 030abd8a
      Lorenzo Pieralisi authored
      Commit 618f535a ("ACPI/IORT: Add single mapping function")
      introduced a function (iort_node_get_id()) to retrieve ids for IORT
      named components.
      
      The iort_node_get_id() takes an index as input to refer to a specific
      mapping entry in the named component IORT node mapping array.
      
      For a mapping entry at a given index, iort_node_get_id() should return
      the id value (through the id_out function parameter) and the IORT node
      output_reference (through function return value) the given mapping entry
      refers to.
      
      Technically output_reference values may differ for different map
      entries, (see diagram below - mapped id values may refer to different eg
      IORT SMMU nodes; the kernel may not be able to handle different
      output_reference values for a given named component but the IORT kernel
      layer should still report the IORT mappings as reported by firmware) but
      current code in iort_node_get_id() fails to use the index function
      parameter to return the correct output_reference value (ie it always
      returns the output_reference value of the first entry in the mapping
      array whilst using the index correctly to retrieve the id value from the
      respective entry).
      
      	|----------------------|
      	|     named component  |
      	|----------------------|
      	|      map entry[0]    |
      	|----------------------|
      	|       id value       |
      	| output_reference----------------> eg SMMU 1
      	|----------------------|
      	|      map entry[1]    |
      	|----------------------|
      	|       id value       |
      	| output_reference----------------> eg SMMU 2
      	|----------------------|
      		    .
      		    .
      		    .
      	|----------------------|
      	|      map entry[N]    |
      	|----------------------|
      	|       id value       |
      	| output_reference----------------> eg SMMU 1
      	|----------------------|
      
      Consequently the iort_node_get_id() function always returns the IORT
      node pointed at by the output_reference value of the first named
      component mapping array entry, irrespective of the index parameter,
      which is a bug.
      
      Update the map array entry pointer computation in iort_node_get_id() to
      take into account the index value, fixing the issue.
      
      Fixes: 618f535a ("ACPI/IORT: Add single mapping function")
      Reported-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Reviewed-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Sinan Kaya <okaya@codeaurora.org>
      Cc: Tomasz Nowicki <tn@semihalf.com>
      Cc: Nate Watterson <nwatters@codeaurora.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      030abd8a
    • Ard Biesheuvel's avatar
      arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA · 6d526ee2
      Ard Biesheuvel authored
      The NUMA code may get confused by the presence of NOMAP regions within
      zones, resulting in spurious BUG() checks where the node id deviates
      from the containing zone's node id.
      
      Since the kernel has no business reasoning about node ids of pages it
      does not own in the first place, enable CONFIG_HOLES_IN_ZONE to ensure
      that such pages are disregarded.
      Acked-by: default avatarRobert Richter <rrichter@cavium.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      6d526ee2
  6. 03 Feb, 2017 5 commits
  7. 02 Feb, 2017 4 commits
  8. 01 Feb, 2017 1 commit
    • Christopher Covington's avatar
      arm64: Work around Falkor erratum 1009 · d9ff80f8
      Christopher Covington authored
      During a TLB invalidate sequence targeting the inner shareable domain,
      Falkor may prematurely complete the DSB before all loads and stores using
      the old translation are observed. Instruction fetches are not subject to
      the conditions of this erratum. If the original code sequence includes
      multiple TLB invalidate instructions followed by a single DSB, onle one of
      the TLB instructions needs to be repeated to work around this erratum.
      While the erratum only applies to cases in which the TLBI specifies the
      inner-shareable domain (*IS form of TLBI) and the DSB is ISH form or
      stronger (OSH, SYS), this changes applies the workaround overabundantly--
      to local TLBI, DSB NSH sequences as well--for simplicity.
      
      Based on work by Shanker Donthineni <shankerd@codeaurora.org>
      Signed-off-by: default avatarChristopher Covington <cov@codeaurora.org>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d9ff80f8
  9. 31 Jan, 2017 1 commit
    • Catalin Marinas's avatar
      arm64: Improve detection of user/non-user mappings in set_pte(_at) · ec663d96
      Catalin Marinas authored
      Commit cab15ce6 ("arm64: Introduce execute-only page access
      permissions") allowed a valid user PTE to have the PTE_USER bit clear.
      As a consequence, the pte_valid_not_user() macro in set_pte() was
      replaced with pte_valid_global() under the assumption that only user
      pages have the nG bit set. EFI mappings, however, also have the nG bit
      set and set_pte() wrongly ignores issuing the DSB+ISB.
      
      This patch reinstates the pte_valid_not_user() macro and adds the
      PTE_UXN bit check since all kernel mappings have this bit set. For
      clarity, pte_exec() is renamed to pte_user_exec() as it only checks for
      the absence of PTE_UXN. Consequently, the user executable check in
      set_pte_at() drops the pte_ng() test since pte_user_exec() is
      sufficient.
      
      Fixes: cab15ce6 ("arm64: Introduce execute-only page access permissions")
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ec663d96
  10. 27 Jan, 2017 3 commits
  11. 26 Jan, 2017 5 commits
  12. 23 Jan, 2017 1 commit
  13. 17 Jan, 2017 1 commit
    • Mark Rutland's avatar
      arm64: entry-ftrace.S: avoid open-coded {adr,ldr}_l · 829d2bd1
      Mark Rutland authored
      Some places in the kernel open-code sequences using ADRP for a symbol
      another instruction using a :lo12: relocation for that same symbol.
      These sequences are easy to get wrong, and more painful to read than is
      necessary. For these reasons, it is preferable to use the
      {adr,ldr,str}_l macros for these cases.
      
      This patch makes use of these in entry-ftrace.S, removing open-coded
      sequences using adrp. This results in a minor code change, since a
      temporary register is not used when generating the address for some
      symbols, but this is fine, as the value of the temporary register is not
      used elsewhere.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      829d2bd1