1. 03 10月, 2014 1 次提交
  2. 30 9月, 2014 1 次提交
    • J
      ARM: 8179/1: kprobes-test: Fix compile error "bad immediate value for offset" · ad684dce
      Jon Medhurst 提交于
      When compiling kprobes-test-arm.c the following error has been observed
      
      /tmp/ccoT403o.s:21439: Error: bad immediate value for offset (4168)
      
      This is caused by the compiler spilling it's literal pool too far away
      from the site which is trying to reference it with a PC relative load.
      This arises because the compiler is underestimating the size of the
      inline assembler code present, which apparently it approximates as 4
      bytes per line or instruction.
      
      We fix this problem by moving the operations which generate more than
      4 bytes out of the text section. Specifically, moving the .ascii
      directives to the .rodata section.
      Signed-off-by: NJon Medhurst <tixy@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ad684dce
  3. 26 9月, 2014 6 次提交
  4. 18 9月, 2014 3 次提交
  5. 16 9月, 2014 3 次提交
    • S
      ARM: 8149/1: perf: Don't sleep while atomic when enabling per-cpu interrupts · 505013bc
      Stephen Boyd 提交于
      Rob Clark reports a sleeping while atomic bug when using perf.
      
      BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:583
      in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
      ------------[ cut here ]------------
      WARNING: CPU: 2 PID: 4828 at ../kernel/locking/mutex.c:479 mutex_lock_nested+0x3a0/0x3e8()
      DEBUG_LOCKS_WARN_ON(in_interrupt())
      Modules linked in:
      CPU: 2 PID: 4828 Comm: Xorg.bin Tainted: G        W      3.17.0-rc3-00234-gd535c45-dirty #819
      [<c0216690>] (unwind_backtrace) from [<c0212174>] (show_stack+0x10/0x14)
      [<c0212174>] (show_stack) from [<c0867cc0>] (dump_stack+0x98/0xb8)
      [<c0867cc0>] (dump_stack) from [<c02492a4>] (warn_slowpath_common+0x70/0x8c)
      [<c02492a4>] (warn_slowpath_common) from [<c02492f0>] (warn_slowpath_fmt+0x30/0x40)
      [<c02492f0>] (warn_slowpath_fmt) from [<c086a3f8>] (mutex_lock_nested+0x3a0/0x3e8)
      [<c086a3f8>] (mutex_lock_nested) from [<c0294d08>] (irq_find_host+0x20/0x9c)
      [<c0294d08>] (irq_find_host) from [<c0769d50>] (of_irq_get+0x28/0x48)
      [<c0769d50>] (of_irq_get) from [<c057d104>] (platform_get_irq+0x1c/0x8c)
      [<c057d104>] (platform_get_irq) from [<c021a06c>] (cpu_pmu_enable_percpu_irq+0x14/0x38)
      [<c021a06c>] (cpu_pmu_enable_percpu_irq) from [<c02b1634>] (flush_smp_call_function_queue+0x88/0x178)
      [<c02b1634>] (flush_smp_call_function_queue) from [<c0214dc0>] (handle_IPI+0x88/0x160)
      [<c0214dc0>] (handle_IPI) from [<c0208930>] (gic_handle_irq+0x64/0x68)
      [<c0208930>] (gic_handle_irq) from [<c0212d04>] (__irq_svc+0x44/0x5c)
      Exception stack(0xe63ddea0 to 0xe63ddee8)
      dea0: 00000001 00000001 00000000 c2f3b200 c16db380 c032d4a0 e63ddf40 60010013
      dec0: 00000000 001fbfd4 00000100 00000000 00000001 e63ddee8 c0284770 c02a2e30
      dee0: 20010013 ffffffff
      [<c0212d04>] (__irq_svc) from [<c02a2e30>] (ktime_get_ts64+0x1c8/0x200)
      [<c02a2e30>] (ktime_get_ts64) from [<c032d4a0>] (poll_select_set_timeout+0x60/0xa8)
      [<c032d4a0>] (poll_select_set_timeout) from [<c032df64>] (SyS_select+0xa8/0x118)
      [<c032df64>] (SyS_select) from [<c020e8e0>] (ret_fast_syscall+0x0/0x48)
      ---[ end trace 0bb583b46342da6f ]---
      INFO: lockdep is turned off.
      
      We don't really need to get the platform irq again when we're
      enabling or disabling the per-cpu irq. Furthermore, we don't
      really need to set and clear bits in the active_irqs bitmask
      because that's only used in the non-percpu irq case to figure out
      when the last CPU PMU has been disabled. Just pass the irq
      directly to the enable/disable functions to clean all this up.
      This should be slightly more efficient and also fix the
      scheduling while atomic bug.
      
      Fixes: bbd64559 "ARM: perf: support percpu irqs for the CPU PMU"
      Reported-by: NRob Clark <robdclark@gmail.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      505013bc
    • N
      ARM: 8148/1: flush TLS and thumbee register state during exec · fbfb872f
      Nathan Lynch 提交于
      The TPIDRURO and TPIDRURW registers need to be flushed during exec;
      otherwise TLS information is potentially leaked.  TPIDRURO in
      particular needs careful treatment.  Since flush_thread basically
      needs the same code used to set the TLS in arm_syscall, pull that into
      a common set_tls helper in tls.h and use it in both places.
      
      Similarly, TEEHBR needs to be cleared during exec as well.  Clearing
      its save slot in thread_info isn't right as there is no guarantee
      that a thread switch will occur before the new program runs.  Just
      setting the register directly is sufficient.
      Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fbfb872f
    • V
      ARM: 8151/1: add missing exports for asm functions required by get_user macro · 7a0bd497
      Victor Kamensky 提交于
      Previous commits that dealt with get_user for 64bit type missed to
      export proper functions, so if get_user macro with particular target/value
      types are used by kernel module modpost would produce 'undefined!' error.
      Solution is to export all required functions.
      Signed-off-by: NVictor Kamensky <victor.kamensky@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7a0bd497
  6. 13 9月, 2014 1 次提交
  7. 03 9月, 2014 1 次提交
    • S
      ARM: 8133/1: use irq_set_affinity with force=false when migrating irqs · a040803a
      Sudeep Holla 提交于
      Since commit 1dbfa187 ("ARM: irq migration: force migration off CPU
      going down") the ARM interrupt migration code on cpu offline calls
      irqchip.irq_set_affinity() with the argument force=true. At the point
      of this change the argument had no effect because it was not used by
      any interrupt chip driver and there was no semantics defined.
      
      This changed with commit 01f8fa4f ("genirq: Allow forcing cpu
      affinity of interrupts") which made the force argument useful to route
      interrupts to not yet online cpus without checking the target cpu
      against the cpu online mask. The following commit ffde1de6
      ("irqchip: gic: Support forced affinity setting") implemented this for
      the GIC interrupt controller.
      
      As a consequence the ARM cpu offline irq migration fails if CPU0 is
      offlined, because CPU0 is still set in the affinity mask and the
      validataion against cpu online mask is skipped to the force argument
      being true. The following first_cpu(mask) selection always selects
      CPU0 as the target.
      
      Solve the issue by calling irq_set_affinity() with force=false from
      the CPU offline irq migration code so the GIC driver validates the
      affinity mask against CPU online mask and therefore removes CPU0 from
      the possible target candidates.
      
      Tested on TC2 hotpluging CPU0 in and out. Without this patch the system
      locks up as the IRQs are not migrated away from CPU0.
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Cc: <stable@vger.kernel.org> # 3.10.x
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a040803a
  8. 27 8月, 2014 3 次提交
  9. 09 8月, 2014 2 次提交
  10. 08 8月, 2014 1 次提交
  11. 02 8月, 2014 3 次提交
  12. 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
  13. 24 7月, 2014 1 次提交
  14. 19 7月, 2014 1 次提交
  15. 18 7月, 2014 10 次提交
  16. 11 7月, 2014 2 次提交