1. 08 11月, 2014 1 次提交
  2. 29 10月, 2014 1 次提交
  3. 19 10月, 2014 1 次提交
    • R
      ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854 · 7fc15054
      Russell King 提交于
      These stock GCC versions miscompile the kernel by incorrectly optimising
      the function epilogue code - by first increasing the stack pointer, and
      then loading entries from below the stack.  This means that an opportune
      interrupt or exception will corrupt the current function's saved state,
      which may result in the parent function seeing different register
      values.
      
      As this bug has been known to result in corrupted filesystems, and these
      buggy compiler versions seem to be frequently used, we have little
      option but to blacklist these compiler versions.
      
      Distributions may have fixed PR58854, but as their compilers are totally
      indistinguishable from the buggy versions, it is unfortunate that this
      also results in those also being blacklisted.  Given the filesystem
      corruption potential of the original, this is the lesser evil.  People
      who want to build with their fixed compiler versions will need to adjust
      the kernel source.  (Distros need to think about the implications of
      fixing such a compiler bug, and consider how to ensure that their fixed
      compiler versions can be detected if they wish to avoid this.)
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7fc15054
  4. 10 10月, 2014 1 次提交
  5. 03 10月, 2014 1 次提交
  6. 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
  7. 26 9月, 2014 8 次提交
  8. 24 9月, 2014 1 次提交
    • E
      ARCH: AUDIT: audit_syscall_entry() should not require the arch · 91397401
      Eric Paris 提交于
      We have a function where the arch can be queried, syscall_get_arch().
      So rather than have every single piece of arch specific code use and/or
      duplicate syscall_get_arch(), just have the audit code use the
      syscall_get_arch() code.
      Based-on-patch-by: NRichard Briggs <rgb@redhat.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Cc: linux-alpha@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-ia64@vger.kernel.org
      Cc: microblaze-uclinux@itee.uq.edu.au
      Cc: linux-mips@linux-mips.org
      Cc: linux@lists.openrisc.net
      Cc: linux-parisc@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-s390@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: sparclinux@vger.kernel.org
      Cc: user-mode-linux-devel@lists.sourceforge.net
      Cc: linux-xtensa@linux-xtensa.org
      Cc: x86@kernel.org
      91397401
  9. 19 9月, 2014 1 次提交
  10. 18 9月, 2014 3 次提交
  11. 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
  12. 14 9月, 2014 1 次提交
  13. 13 9月, 2014 1 次提交
  14. 04 9月, 2014 1 次提交
    • A
      seccomp,x86,arm,mips,s390: Remove nr parameter from secure_computing · a4412fc9
      Andy Lutomirski 提交于
      The secure_computing function took a syscall number parameter, but
      it only paid any attention to that parameter if seccomp mode 1 was
      enabled.  Rather than coming up with a kludge to get the parameter
      to work in mode 2, just remove the parameter.
      
      To avoid churn in arches that don't have seccomp filters (and may
      not even support syscall_get_nr right now), this leaves the
      parameter in secure_computing_strict, which is now a real function.
      
      For ARM, this is a bit ugly due to the fact that ARM conditionally
      supports seccomp filters.  Fixing that would probably only be a
      couple of lines of code, but it should be coordinated with the audit
      maintainers.
      
      This will be a slight slowdown on some arches.  The right fix is to
      pass in all of seccomp_data instead of trying to make just the
      syscall nr part be fast.
      
      This is a prerequisite for making two-phase seccomp work cleanly.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux-s390@vger.kernel.org
      Cc: x86@kernel.org
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      a4412fc9
  15. 03 9月, 2014 2 次提交
  16. 27 8月, 2014 4 次提交
  17. 09 8月, 2014 2 次提交
  18. 08 8月, 2014 1 次提交
  19. 02 8月, 2014 3 次提交
  20. 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
  21. 24 7月, 2014 1 次提交
  22. 19 7月, 2014 1 次提交