1. 25 10月, 2017 1 次提交
  2. 18 10月, 2017 2 次提交
  3. 10 10月, 2017 2 次提交
  4. 06 10月, 2017 2 次提交
  5. 05 10月, 2017 1 次提交
    • M
      arm64: Use larger stacks when KASAN is selected · b02faed1
      Mark Rutland 提交于
      AddressSanitizer instrumentation can significantly bloat the stack, and
      with GCC 7 this can result in stack overflows at boot time in some
      configurations.
      
      We can avoid this by doubling our stack size when KASAN is in use, as is
      already done on x86 (and has been since KASAN was introduced).
      Regardless of other patches to decrease KASAN's stack utilization,
      kernels built with KASAN will always require more stack space than those
      built without, and we should take this into account.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      b02faed1
  6. 02 10月, 2017 2 次提交
  7. 29 9月, 2017 2 次提交
    • W
      arm64: fault: Route pte translation faults via do_translation_fault · 760bfb47
      Will Deacon 提交于
      We currently route pte translation faults via do_page_fault, which elides
      the address check against TASK_SIZE before invoking the mm fault handling
      code. However, this can cause issues with the path walking code in
      conjunction with our word-at-a-time implementation because
      load_unaligned_zeropad can end up faulting in kernel space if it reads
      across a page boundary and runs into a page fault (e.g. by attempting to
      read from a guard region).
      
      In the case of such a fault, load_unaligned_zeropad has registered a
      fixup to shift the valid data and pad with zeroes, however the abort is
      reported as a level 3 translation fault and we dispatch it straight to
      do_page_fault, despite it being a kernel address. This results in calling
      a sleeping function from atomic context:
      
        BUG: sleeping function called from invalid context at arch/arm64/mm/fault.c:313
        in_atomic(): 0, irqs_disabled(): 0, pid: 10290
        Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
        [...]
        [<ffffff8e016cd0cc>] ___might_sleep+0x134/0x144
        [<ffffff8e016cd158>] __might_sleep+0x7c/0x8c
        [<ffffff8e016977f0>] do_page_fault+0x140/0x330
        [<ffffff8e01681328>] do_mem_abort+0x54/0xb0
        Exception stack(0xfffffffb20247a70 to 0xfffffffb20247ba0)
        [...]
        [<ffffff8e016844fc>] el1_da+0x18/0x78
        [<ffffff8e017f399c>] path_parentat+0x44/0x88
        [<ffffff8e017f4c9c>] filename_parentat+0x5c/0xd8
        [<ffffff8e017f5044>] filename_create+0x4c/0x128
        [<ffffff8e017f59e4>] SyS_mkdirat+0x50/0xc8
        [<ffffff8e01684e30>] el0_svc_naked+0x24/0x28
        Code: 36380080 d5384100 f9400800 9402566d (d4210000)
        ---[ end trace 2d01889f2bca9b9f ]---
      
      Fix this by dispatching all translation faults to do_translation_faults,
      which avoids invoking the page fault logic for faults on kernel addresses.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NAnkit Jain <ankijain@codeaurora.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      760bfb47
    • W
      arm64: mm: Use READ_ONCE when dereferencing pointer to pte table · f069faba
      Will Deacon 提交于
      On kernels built with support for transparent huge pages, different CPUs
      can access the PMD concurrently due to e.g. fast GUP or page_vma_mapped_walk
      and they must take care to use READ_ONCE to avoid value tearing or caching
      of stale values by the compiler. Unfortunately, these functions call into
      our pgtable macros, which don't use READ_ONCE, and compiler caching has
      been observed to cause the following crash during ext4 writeback:
      
      PC is at check_pte+0x20/0x170
      LR is at page_vma_mapped_walk+0x2e0/0x540
      [...]
      Process doio (pid: 2463, stack limit = 0xffff00000f2e8000)
      Call trace:
      [<ffff000008233328>] check_pte+0x20/0x170
      [<ffff000008233758>] page_vma_mapped_walk+0x2e0/0x540
      [<ffff000008234adc>] page_mkclean_one+0xac/0x278
      [<ffff000008234d98>] rmap_walk_file+0xf0/0x238
      [<ffff000008236e74>] rmap_walk+0x64/0xa0
      [<ffff0000082370c8>] page_mkclean+0x90/0xa8
      [<ffff0000081f3c64>] clear_page_dirty_for_io+0x84/0x2a8
      [<ffff00000832f984>] mpage_submit_page+0x34/0x98
      [<ffff00000832fb4c>] mpage_process_page_bufs+0x164/0x170
      [<ffff00000832fc8c>] mpage_prepare_extent_to_map+0x134/0x2b8
      [<ffff00000833530c>] ext4_writepages+0x484/0xe30
      [<ffff0000081f6ab4>] do_writepages+0x44/0xe8
      [<ffff0000081e5bd4>] __filemap_fdatawrite_range+0xbc/0x110
      [<ffff0000081e5e68>] file_write_and_wait_range+0x48/0xd8
      [<ffff000008324310>] ext4_sync_file+0x80/0x4b8
      [<ffff0000082bd434>] vfs_fsync_range+0x64/0xc0
      [<ffff0000082332b4>] SyS_msync+0x194/0x1e8
      
      This is because page_vma_mapped_walk loads the PMD twice before calling
      pte_offset_map: the first time without READ_ONCE (where it gets all zeroes
      due to a concurrent pmdp_invalidate) and the second time with READ_ONCE
      (where it sees a valid table pointer due to a concurrent pmd_populate).
      However, the compiler inlines everything and caches the first value in
      a register, which is subsequently used in pte_offset_phys which returns
      a junk pointer that is later dereferenced when attempting to access the
      relevant pte.
      
      This patch fixes the issue by using READ_ONCE in pte_offset_phys to ensure
      that a stale value is not used. Whilst this is a point fix for a known
      failure (and simple to backport), a full fix moving all of our page table
      accessors over to {READ,WRITE}_ONCE and consistently using READ_ONCE in
      page_vma_mapped_walk is in the works for a future kernel release.
      
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Timur Tabi <timur@codeaurora.org>
      Cc: <stable@vger.kernel.org>
      Fixes: f27176cf ("mm: convert page_mkclean_one() to use page_vma_mapped_walk()")
      Tested-by: NRichard Ruigrok <rruigrok@codeaurora.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      f069faba
  8. 27 9月, 2017 1 次提交
  9. 26 9月, 2017 1 次提交
  10. 21 9月, 2017 1 次提交
  11. 20 9月, 2017 1 次提交
  12. 19 9月, 2017 1 次提交
  13. 18 9月, 2017 4 次提交
  14. 17 9月, 2017 2 次提交
    • J
      arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0 · 3f241bfa
      Jagan Teki 提交于
      Since current tree support AXP803 regulators, replace
      fixed regulator with AXP803 dcdc1 regulator.
      
      Tested on pine64.
      Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
      Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      3f241bfa
    • H
      Revert "arm64: dts: rockchip: Add basic cpu frequencies for RK3368" · 6354a06c
      Heiko Stuebner 提交于
      This reverts commit 6f2dea1f.
      
      Without accurate cpu regulators being set for boards this will wreak havoc
      when cpufreq-dt begins to set new frequencies without adjusting the core
      frequency.
      
      Additionally the rk3368 has an unsolved issue in that it has two separate
      cpu clusters with separate clock lines but only one cpu supply regulator
      for both clusters, which causes even more problems.
      
      While it seems that originally only one cluster was supposed to be active
      at a time (big or little), talking with real users of the hardware
      revealed that having all 8 cores accessible at 1.2GHz max is way more
      liked than having 4 cores at 1.5GHz max. Such an approach needs changes
      to cpufreq and/or opp though to control the two separate clock lines when
      setting both clusters to the same frequencies.
      
      In any case, having the OPPs in the dts at this point in time is
      undesireable, so remove them again for now.
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      6354a06c
  15. 14 9月, 2017 1 次提交
  16. 09 9月, 2017 1 次提交
  17. 06 9月, 2017 9 次提交
  18. 05 9月, 2017 2 次提交
  19. 01 9月, 2017 1 次提交
  20. 31 8月, 2017 3 次提交