1. 26 8月, 2016 8 次提交
    • J
      Revert "arm64: hibernate: Refuse to hibernate if the boot cpu is offline" · b2d8b0cb
      James Morse 提交于
      Now that we use the MPIDR to resume on the same CPU that we hibernated on,
      we no longer need to refuse to hibernate if the boot cpu is offline. (Which
      we can't possibly know if kexec causes logical CPUs to be renumbered).
      
      This reverts commit 1fe492ce.
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      b2d8b0cb
    • J
      arm64: hibernate: Resume when hibernate image created on non-boot CPU · 8ec058fd
      James Morse 提交于
      disable_nonboot_cpus() assumes that the lowest numbered online CPU is
      the boot CPU, and that this is the correct CPU to run any power
      management code on.
      
      On arm64 CPU0 can be taken offline. For hibernate/resume this means we
      may hibernate on a CPU other than CPU0. If the system is rebooted with
      kexec 'CPU0' will be assigned to a different CPU. This complicates
      hibernate/resume as now we can't trust the CPU numbers.
      
      We currently forbid hibernate if CPU0 has been hotplugged out to avoid
      this situation without kexec.
      
      Save the MPIDR of the CPU we hibernated on in the hibernate arch-header,
      use hibernate_resume_nonboot_cpu_disable() to direct which CPU we should
      resume on based on the MPIDR of the CPU we hibernated on. This allows us to
      hibernate/resume on any CPU, even if the logical numbers have been
      shuffled by kexec.
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      8ec058fd
    • M
      arm64: always enable DEBUG_RODATA and remove the Kconfig option · 40982fd6
      Mark Rutland 提交于
      Follow the example set by x86 in commit 9ccaf77c ("x86/mm:
      Always enable CONFIG_DEBUG_RODATA and remove the Kconfig option"), and
      make these protections a fundamental security feature rather than an
      opt-in. This also results in a minor code simplification.
      
      For those rare cases when users wish to disable this protection (e.g.
      for debugging), this can be done by passing 'rodata=off' on the command
      line.
      
      As DEBUG_RODATA_ALIGN is only intended to address a performance/memory
      tradeoff, and does not affect correctness, this is left user-selectable.
      DEBUG_MODULE_RONX is also left user-selectable until the core code
      provides a boot-time option to disable the protection for debugging
      use-cases.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NKees Cook <keescook@chromium.org>
      Acked-by: NLaura Abbott <labbott@redhat.com>
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      40982fd6
    • A
      arm64: mark reserved memblock regions explicitly in iomem · e7cd1903
      AKASHI Takahiro 提交于
      Kdump(kexec-tools) parses /proc/iomem to identify all the memory regions
      on the system. Since the current kernel names "nomap" regions, like UEFI
      runtime services code/data, as "System RAM," kexec-tools sets up elf core
      header to include them in a crash dump file (/proc/vmcore).
      
      Then crash dump kernel parses UEFI memory map again, re-marks those regions
      as "nomap" and does not create a memory mapping for them unlike the other
      areas of System RAM. In this case, copying /proc/vmcore through
      copy_oldmem_page() on crash dump kernel will end up with a kernel abort,
      as reported in [1].
      
      This patch names all the "nomap" regions explicitly as "reserved" so that
      we can exclude them from a crash dump file. acpi_os_ioremap() must also
      be modified because those regions have WB attributes [2].
      
      Apart from kdump, this change also matches x86's use of acpi (and
      /proc/iomem).
      
      [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/448186.html
      [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/450089.htmlReviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: NJames Morse <james.morse@arm.com>
      Reviewed-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      e7cd1903
    • 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
    • J
      arm64: Create sections.h · ee78fdc7
      James Morse 提交于
      Each time new section markers are added, kernel/vmlinux.ld.S is updated,
      and new extern char __start_foo[] definitions are scattered through the
      tree.
      
      Create asm/include/sections.h to collect these definitions (and include
      the existing asm-generic version).
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Tested-by: NMark Rutland <mark.rutland@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      ee78fdc7
    • P
      arm64: kprobe: Always clear pstate.D in breakpoint exception handler · 7419333f
      Pratyush Anand 提交于
      Whenever we are hitting a kprobe from a none-kprobe debug exception handler,
      we hit an infinite occurrences of "Unexpected kernel single-step exception
      at EL1"
      
      PSTATE.D is debug exception mask bit. It is set whenever we enter into an
      exception mode. When it is set then Watchpoint, Breakpoint, and Software
      Step exceptions are masked. However, software Breakpoint Instruction
      exceptions can never be masked. Therefore, if we ever execute a BRK
      instruction, irrespective of D-bit setting, we will be receiving a
      corresponding breakpoint exception.
      
      For example:
      
      - We are executing kprobe pre/post handler, and kprobe has been inserted in
        one of the instruction of a function called by handler. So, it executes
        BRK instruction and we land into the case of KPROBE_REENTER. (This case is
        already handled by current code)
      
      - We are executing uprobe handler or any other BRK handler such as in
        WARN_ON (BRK BUG_BRK_IMM), and we trace that path using kprobe.So, we
        enter into kprobe breakpoint handler,from another BRK handler.(This case
        is not being handled currently)
      
      In all such cases kprobe breakpoint exception will be raised when we were
      already in debug exception mode. SPSR's D bit (bit 9) shows the value of
      PSTATE.D immediately before the exception was taken. So, in above example
      cases we would find it set in kprobe breakpoint handler.  Single step
      exception will always be followed by a kprobe breakpoint exception.However,
      it will only be raised gracefully if we clear D bit while returning from
      breakpoint exception.  If D bit is set then, it results into undefined
      exception and when it's handler enables dbg then single step exception is
      generated, however it will never be handled(because address does not match
      and therefore treated as unexpected).
      
      This patch clears D-flag unconditionally in setup_singlestep, so that we can
      always get single step exception correctly after returning from breakpoint
      exception. Additionally, it also removes D-flag set statement for
      KPROBE_REENTER return path, because debug exception for KPROBE_REENTER will
      always take place in a debug exception state. So, D-flag will already be set
      in this case.
      Acked-by: NSandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: NPratyush Anand <panand@redhat.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      7419333f
  2. 22 8月, 2016 7 次提交
  3. 18 8月, 2016 1 次提交
  4. 13 8月, 2016 3 次提交
    • M
      arm64: hibernate: handle allocation failures · dfbca61a
      Mark Rutland 提交于
      In create_safe_exec_page(), we create a copy of the hibernate exit text,
      along with some page tables to map this via TTBR0. We then install the
      new tables in TTBR0.
      
      In swsusp_arch_resume() we call create_safe_exec_page() before trying a
      number of operations which may fail (e.g. copying the linear map page
      tables). If these fail, we bail out of swsusp_arch_resume() and return
      an error code, but leave TTBR0 as-is. Subsequently, the core hibernate
      code will call free_basic_memory_bitmaps(), which will free all of the
      memory allocations we made, including the page tables installed in
      TTBR0.
      
      Thus, we may have TTBR0 pointing at dangling freed memory for some
      period of time. If the hibernate attempt was triggered by a user
      requesting a hibernate test via the reboot syscall, we may return to
      userspace with the clobbered TTBR0 value.
      
      Avoid these issues by reorganising swsusp_arch_resume() such that we
      have no failure paths after create_safe_exec_page(). We also add a check
      that the zero page allocation succeeded, matching what we have for other
      allocations.
      
      Fixes: 82869ac5 ("arm64: kernel: Add support for hibernate/suspend-to-disk")
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NJames Morse <james.morse@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: <stable@vger.kernel.org> # 4.7+
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      dfbca61a
    • M
      arm64: hibernate: avoid potential TLB conflict · 0194e760
      Mark Rutland 提交于
      In create_safe_exec_page we install a set of global mappings in TTBR0,
      then subsequently invalidate TLBs. While TTBR0 points at the zero page,
      and the TLBs should be free of stale global entries, we may have stale
      ASID-tagged entries (e.g. from the EFI runtime services mappings) for
      the same VAs. Per the ARM ARM these ASID-tagged entries may conflict
      with newly-allocated global entries, and we must follow a
      Break-Before-Make approach to avoid issues resulting from this.
      
      This patch reworks create_safe_exec_page to invalidate TLBs while the
      zero page is still in place, ensuring that there are no potential
      conflicts when the new TTBR0 value is installed. As a single CPU is
      online while this code executes, we do not need to perform broadcast TLB
      maintenance, and can call local_flush_tlb_all(), which also subsumes
      some barriers. The remaining assembly is converted to use write_sysreg()
      and isb().
      
      Other than this, we safely manipulate TTBRs in the hibernate dance. The
      code we install as part of the new TTBR0 mapping (the hibernated
      kernel's swsusp_arch_suspend_exit) installs a zero page into TTBR1,
      invalidates TLBs, then installs its preferred value. Upon being restored
      to the middle of swsusp_arch_suspend, the new image will call
      __cpu_suspend_exit, which will call cpu_uninstall_idmap, installing the
      zero page in TTBR0 and invalidating all TLB entries.
      
      Fixes: 82869ac5 ("arm64: kernel: Add support for hibernate/suspend-to-disk")
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NJames Morse <james.morse@arm.com>
      Tested-by: NJames Morse <james.morse@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: <stable@vger.kernel.org> # 4.7+
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      0194e760
    • 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
  5. 12 8月, 2016 1 次提交
  6. 09 8月, 2016 1 次提交
  7. 29 7月, 2016 2 次提交
    • A
      arm64: relocatable: suppress R_AARCH64_ABS64 relocations in vmlinux · 08cc55b2
      Ard Biesheuvel 提交于
      The linker routines that we rely on to produce a relocatable PIE binary
      treat it as a shared ELF object in some ways, i.e., it emits symbol based
      R_AARCH64_ABS64 relocations into the final binary since doing so would be
      appropriate when linking a shared library that is subject to symbol
      preemption. (This means that an executable can override certain symbols
      that are exported by a shared library it is linked with, and that the
      shared library *must* update all its internal references as well, and point
      them to the version provided by the executable.)
      
      Symbol preemption does not occur for OS hosted PIE executables, let alone
      for vmlinux, and so we would prefer to get rid of these symbol based
      relocations. This would allow us to simplify the relocation routines, and
      to strip the .dynsym, .dynstr and .hash sections from the binary. (Note
      that these are tiny, and are placed in the .init segment, but they clutter
      up the vmlinux binary.)
      
      Note that these R_AARCH64_ABS64 relocations are only emitted for absolute
      references to symbols defined in the linker script, all other relocatable
      quantities are covered by anonymous R_AARCH64_RELATIVE relocations that
      simply list the offsets to all 64-bit values in the binary that need to be
      fixed up based on the offset between the link time and run time addresses.
      
      Fortunately, GNU ld has a -Bsymbolic option, which is intended for shared
      libraries to allow them to ignore symbol preemption, and unconditionally
      bind all internal symbol references to its own definitions. So set it for
      our PIE binary as well, and get rid of the asoociated sections and the
      relocation code that processes them.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: fixed conflict with __dynsym_offset linker script entry]
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      08cc55b2
    • A
      arm64: vmlinux.lds: make __rela_offset and __dynsym_offset ABSOLUTE · d6732fc4
      Ard Biesheuvel 提交于
      Due to the untyped KIMAGE_VADDR constant, the linker may not notice
      that the __rela_offset and __dynsym_offset expressions are absolute
      values (i.e., are not subject to relocation). This does not matter for
      KASLR, but it does confuse kallsyms in relative mode, since it uses
      the lowest non-absolute symbol address as the anchor point, and expects
      all other symbol addresses to be within 4 GB of it.
      
      Fix this by qualifying these expressions as ABSOLUTE() explicitly.
      
      Fixes: 0cd3defe ("arm64: kernel: perform relocation processing from ID map")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      d6732fc4
  8. 27 7月, 2016 1 次提交
  9. 22 7月, 2016 2 次提交
  10. 21 7月, 2016 5 次提交
    • S
      arm64: Honor nosmp kernel command line option · e75118a7
      Suzuki K Poulose 提交于
      Passing "nosmp" should boot the kernel with a single processor, without
      provision to enable secondary CPUs even if they are present. "nosmp" is
      implemented by setting maxcpus=0. At the moment we still mark the secondary
      CPUs present even with nosmp, which allows the userspace to bring them
      up. This patch corrects the smp_prepare_cpus() to honor the maxcpus == 0.
      
      Commit 44dbcc93 ("arm64: Fix behavior of maxcpus=N") fixed the
      behavior for maxcpus >= 1, but broke maxcpus = 0.
      
      Fixes: 44dbcc93 ("arm64: Fix behavior of maxcpus=N")
      Cc: <stable@vger.kernel.org> # 4.7+
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      [catalin.marinas@arm.com: updated code comment]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      e75118a7
    • S
      arm64: Fix incorrect per-cpu usage for boot CPU · 9113c2aa
      Suzuki K Poulose 提交于
      In smp_prepare_boot_cpu(), we invoke cpuinfo_store_boot_cpu to  store
      the cpuinfo in a per-cpu ptr, before initialising the per-cpu offset for
      the boot CPU. This patch reorders the sequence to make sure we initialise
      the per-cpu offset before accessing the per-cpu area.
      
      Commit 4b998ff1 ("arm64: Delay cpuinfo_store_boot_cpu") fixed the
      issue where we modified the per-cpu area even before the kernel initialises
      the per-cpu areas, but failed to wait until the boot cpu updated it's
      offset.
      
      Fixes: 4b998ff1 ("arm64: Delay cpuinfo_store_boot_cpu")
      Cc: <stable@vger.kernel.org> # 4.4+
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      9113c2aa
    • C
      arm64: kprobes: Add KASAN instrumentation around stack accesses · f7e35c5b
      Catalin Marinas 提交于
      This patch disables KASAN around the memcpy from/to the kernel or IRQ
      stacks to avoid warnings like below:
      
      BUG: KASAN: stack-out-of-bounds in setjmp_pre_handler+0xe4/0x170 at addr ffff800935cbbbc0
      Read of size 128 by task swapper/0/1
      page:ffff7e0024d72ec0 count:0 mapcount:0 mapping:          (null) index:0x0
      flags: 0x1000000000000000()
      page dumped because: kasan: bad access detected
      CPU: 4 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc4+ #1
      Hardware name: ARM Juno development board (r0) (DT)
      Call trace:
      [<ffff20000808ad88>] dump_backtrace+0x0/0x280
      [<ffff20000808b01c>] show_stack+0x14/0x20
      [<ffff200008563a64>] dump_stack+0xa4/0xc8
      [<ffff20000824a1fc>] kasan_report_error+0x4fc/0x528
      [<ffff20000824a5e8>] kasan_report+0x40/0x48
      [<ffff20000824948c>] check_memory_region+0x144/0x1a0
      [<ffff200008249814>] memcpy+0x34/0x68
      [<ffff200008c3ee2c>] setjmp_pre_handler+0xe4/0x170
      [<ffff200008c3ec5c>] kprobe_breakpoint_handler+0xec/0x1d8
      [<ffff2000080853a4>] brk_handler+0x5c/0xa0
      [<ffff2000080813f0>] do_debug_exception+0xa0/0x138
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      f7e35c5b
    • M
      arm64: kprobes: Cleanup jprobe_return · 3b7d14e9
      Marc Zyngier 提交于
      jprobe_return seems to have aged badly. Comments referring to
      non-existent behaviours, and a dangerous habit of messing
      with registers without telling the compiler.
      
      This patches applies the following remedies:
      - Fix the comments to describe the actual behaviour
      - Tidy up the asm sequence to directly assign the
        stack pointer without clobbering extra registers
      - Mark the rest of the function as unreachable() so
        that the compiler knows that there is no need for
        an epilogue
      - Stop making jprobe_return_break a global function
        (you really don't want to call that guy, and it isn't
        even a function).
      
      Tested with tcp_probe.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      3b7d14e9
    • M
      arm64: kprobes: Fix overflow when saving stack · ab4c1325
      Marc Zyngier 提交于
      The MIN_STACK_SIZE macro tries evaluate how much stack space needs
      to be saved in the jprobes_stack array, sized at 128 bytes.
      
      When using the IRQ stack, said macro can happily return up to
      IRQ_STACK_SIZE, which is 16kB. Mayhem follows.
      
      This patch fixes things by getting rid of the crazy macro and
      limiting the copy to be at most the size of the jprobes_stack
      array, no matter which stack we're on.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      ab4c1325
  11. 20 7月, 2016 1 次提交
  12. 19 7月, 2016 8 次提交