1. 26 9月, 2014 2 次提交
  2. 27 8月, 2014 1 次提交
  3. 09 8月, 2014 2 次提交
  4. 08 8月, 2014 1 次提交
  5. 02 8月, 2014 3 次提交
  6. 30 7月, 2014 1 次提交
    • L
      arm: Add devicetree fixup machine function · 5a12a597
      Laura Abbott 提交于
      Commit 1c2f87c2
      (ARM: 8025/1: Get rid of meminfo) dropped the upper bound on
      the number of memory banks that can be added as there was no
      technical need in the kernel. It turns out though, some bootloaders
      (specifically the arndale-octa exynos boards) may pass invalid memory
      information and rely on the kernel to not parse this data. This is a
      bug in the bootloader but we still need to work around this.
      Work around this by introducing a dt_fixup function. This function
      gets called before the flattened devicetree is scanned for memory
      and the like. In this fixup function for exynos, limit the maximum
      number of memory regions in the devicetree.
      Signed-off-by: NLaura Abbott <lauraa@codeaurora.org>
      Tested-by: NAndreas Färber <afaerber@suse.de>
      [glikely: Added a comment and fixed up function name]
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      5a12a597
  7. 24 7月, 2014 1 次提交
  8. 19 7月, 2014 1 次提交
  9. 18 7月, 2014 10 次提交
  10. 11 7月, 2014 2 次提交
  11. 09 7月, 2014 2 次提交
    • J
      ARM: perf: disable the pagefault handler when reading from user space · 4b2974fa
      Jean Pihet 提交于
      Under perf, the fp unwinding scheme requires access to user space memory
      and can provoke a pagefault via call to __copy_from_user_inatomic from
      user_backtrace. This unwinding can take place in response to an interrupt
      (__perf_event_overflow). This is undesirable as we may already have
      mmap_sem held for write. One example being a process that calls mprotect
      just as a the PMU counters overflow.
      
      An example that can provoke this behaviour:
      perf record -e event:tocapture --call-graph fp ./application_to_test
      
      This patch addresses this issue by disabling pagefaults briefly in
      user_backtrace (as is done in the other architectures: ARM64, x86, Sparc etc.).
      
      Without the patch a deadlock occurs when __perf_event_overflow is called
      while reading the data from the user space:
      
       [ INFO: possible recursive locking detected ]
       3.16.0-rc2-00038-g0ed7ff6 #46 Not tainted
       ---------------------------------------------
       stress/1634 is trying to acquire lock:
       (&mm->mmap_sem){++++++}, at: [<c001dc04>] do_page_fault+0xa8/0x428
      
       but task is already holding lock:
       (&mm->mmap_sem){++++++}, at: [<c00f4098>] SyS_mprotect+0xa8/0x1c8
      
       other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&mm->mmap_sem);
        lock(&mm->mmap_sem);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
       2 locks held by stress/1634:
       #0:  (&mm->mmap_sem){++++++}, at: [<c00f4098>] SyS_mprotect+0xa8/0x1c8
       #1:  (rcu_read_lock){......}, at: [<c00c29dc>] __perf_event_overflow+0x120/0x294
      
       stack backtrace:
       CPU: 1 PID: 1634 Comm: stress Not tainted 3.16.0-rc2-00038-g0ed7ff6 #46
       [<c0017c8c>] (unwind_backtrace) from [<c0012eec>] (show_stack+0x20/0x24)
       [<c0012eec>] (show_stack) from [<c04de914>] (dump_stack+0x7c/0x98)
       [<c04de914>] (dump_stack) from [<c006a360>] (__lock_acquire+0x1484/0x1cf0)
       [<c006a360>] (__lock_acquire) from [<c006b14c>] (lock_acquire+0xa4/0x11c)
       [<c006b14c>] (lock_acquire) from [<c04e3880>] (down_read+0x40/0x7c)
       [<c04e3880>] (down_read) from [<c001dc04>] (do_page_fault+0xa8/0x428)
       [<c001dc04>] (do_page_fault) from [<c00084ec>] (do_DataAbort+0x44/0xa8)
       [<c00084ec>] (do_DataAbort) from [<c0013a1c>] (__dabt_svc+0x3c/0x60)
       Exception stack(0xed7c5ae0 to 0xed7c5b28)
       5ae0: ed7c5b5c b6dadff4 ffffffec 00000000 b6dadff4 ebc08000 00000000 ebc08000
       5b00: 0000007e 00000000 ed7c4000 ed7c5b94 00000014 ed7c5b2c c001a438 c0236c60
       5b20: 00000013 ffffffff
       [<c0013a1c>] (__dabt_svc) from [<c0236c60>] (__copy_from_user+0xa4/0x3a4)
      Acked-by: NSteve Capper <steve.capper@linaro.org>
      Signed-off-by: NJean Pihet <jean.pihet@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      4b2974fa
    • J
      ARM: perf: Check that current->mm is alive before getting user callchain · a7cc9100
      Jean Pihet 提交于
      An event may occur when an mm is already released.
      
      As per commit 20afc60f
       'x86, perf: Check that current->mm is alive before getting user callchain'
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NJean Pihet <jean.pihet@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      a7cc9100
  12. 02 7月, 2014 10 次提交
  13. 29 6月, 2014 1 次提交
  14. 19 6月, 2014 1 次提交
    • R
      ARM: perf: fix compiler warning with gcc 4.6.4 (and tidy code) · 6a78371a
      Russell King 提交于
      GCC 4.6.4 spits out the following warning when building perf_event_v7.c:
      
      arch/arm/kernel/perf_event_v7.c: In function 'krait_pmu_get_event_idx':
      arch/arm/kernel/perf_event_v7.c:1927:6: warning: 'bit' may be used uninitialized in this function
      
      While upgrading the version of gcc may solve this, the code can also be
      organised to be more efficient by not carrying more local variables than
      is necessary across the armv7pmu_get_event_idx function call.  If we set
      'bit' to -1 (which is invalid for clear_bit) we can use that as an
      indication whether we need to clear a bit after this function.
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6a78371a
  15. 08 6月, 2014 1 次提交
  16. 07 6月, 2014 1 次提交